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ABSTRACT 


The Major Weapon Systems Acquisition Process requires the acquiring 
organizations to make long-tenn resource commitments, whereas the defense budgets of 
many nations have declined over the past decade. Therefore, it is imperative for program 
managers and acquisition practitioners to make informed decisions not only considering 
the up-front costs, which are related to fielding of the system, but considering all the costs 
expected to be incurred throughout the system’s planned life. 

In this study, the major systems acquisition process, and its underlying concepts, 
life-cycle costing, and cost estimation techniques have been discussed, and the strategies 
that enable the PMO to optimize the life-cycle cost of the system are studied in a case 
study approach. The ATACMS lA missile system has been chosen as the study case. The 
life-cycle cost of the ATACMS lA missile system has been estimated; sensitivity and 
uncertainty analyses have been conducted by utilizing the Cost Analysis Strategy 
Assessment (CASA) estimating model in order to develop strategies which will 
eventually reduce the life-cycle cost of the system. The performance and cost figures used 
in the model are assumed by the author, due to sensitivity of the actual data. However, the 
model and the analysis results provide valuable guidance for the PMO, and the analysis 
methodology is applicable to any weapon systems acquisition program. 
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I. INTRODUCTION 


A. BACKGROUND 

The lessons learned from the history of the modem warfare imposes that 
technological superiority is one of the most important decisive factors in the conduct of 
warfare, providing a comparative advantage to the nation that owns it. Therefore, 
modernization of the armed forces, and acquiring irmovative weapon systems has been a 
primary consideration in many nations’ defense planning strategies. 

On the other hand, the defense budgets of the most nations have been exposed to 
downsizing throughout the past decade, thus the most efficient and effective use of tax 
payers’ money and providing the best value to the acquiring agencies has been the most 
important issue for defense acquisition organizations. Furthermore the fast proliferation 
and high obsolescence rates of technology complicate the requirements for the formal 
systems acquisition process: The weapon systems acquisition process should be robust to 
incorporate the latest technologies into system solutions, it should provide the best value 
to the acquiring organizations, and it also should realize best utilization of limited defense 
resources. One of the prerequisites for that kind of acquisition process is to adopt a life- 
cycle oriented approach in terms of cost, supportability, and operational availabihty. 

In order to explore opportunities, apply theoretical knowledge base into practice, 
and test the life-cycle oriented approach to weapon systems acquisition decisions; this 
study is performed. The thesis studies all the issues that are associated with adoption of 
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the life-cycle oriented approach; then estimates the probable Life-cycle Costs (LCC) and 
expected operational availability of a major weapon system; and analyses the parameters 
that affect the LCC and operational availability of the system utilizing a case study 
approach. The ATACMS lA Missile System Acquisition Program has been adopted as 
the study case. 

B. THE RESEARCH QUESTIONS 

1. Primary Research Question 

What are the elements of the LCC for the major weapon systems and what are the 
primary cost drivers? Are they controllable, if they are, what are the methods available, 
and what are the effects of performance improvements in system reliability, 
supportability, and maintainability; and in the logistics processes and organizations 
associated with the system on total ownership costs and system operational availability? 

2. Secondary Research Questions 

1. What is the relationship between the system reliability and maintainability, 
and the operational availability and LCC? 

2. What are the effects of the learning and production rates on system 
acquisition costs? 

3. What are the effects of Innovative Business Practices, such as Integrated 
Product and Process Development (IPPD) on system LCC? 
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4. 


What are the problems experienced in the traditional major weapon 


systems acquisition process? 

C. SCOPE, LIMITATIONS 

The study is conducted to explore the LCC drivers for the major weapon systems, 
and the available techniques and practices that would enable program managers to 
optimize system LCC within the framework of case study on the ATACMS LA missile 
system. The cost and performance data figures pertaining to the system are assmned by 
the author rather than being actual values. 

D. ORGANIZATION OF Tl^ THESIS 

This thesis is divided into five chapters. Chapter I provides the background, the 
research questions, and the scope of the study. 

Chapter n presents a comprehensive overview of the major weapon systems 
acquisition process, the inherent problems in the process, the solution approaches adopted 
by DoD to overcome those problems; an in-depth discussion of system development and 
support processes, such as the systems engineering process, supportability analysis, 
hitegrated Product and Process Development (IPPD) approach etc; and then introduces 
life-cycle costing approach for major weapon systems. 
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Chapter in builds the body of knowledge for cost estimation including discussion 
of estimating techniques, estimation methodology, and estimation tools such as learning 
and production rate curves, sensitivity analysis, and cost risk analysis. 

Chapter IV includes the application of life-cycle cost estimating process to the 
ATACMS lA Missile System, and analyses such as sensitivity and cost uncertainty for 
estimated life-cycle costs. Finally, Chapter V presents the conclusions and 
recommendations derived from the study. 
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II. OVERVIEW OF MAJOR SYSTEMS ACQUISITION PROCESS 

AND CONCEPTS 

This chapter of the thesis is organized in order to build a knowledge base about 
the major systems acquisition process, including the new process mandated by the rewrite 
of DoD 5000.1 dated October 2000. These include the system development process, its 
underlying concepts, and sub-processes such as supportability analysis; and life-cycle 
costing, and the effects of innovative business practices on system LCC. 

A. MAJOR SYSTEMS ACQUISITION PROCESS 

A major system can be described as 

....a combination of elements that will function together to 
produce the capabilities required to fulfill a mission need. The elements 
may include hardware, equipment, software, or any combination thereof, 
but exclude construction or other improvements to real property. [Ref. 1] 

The acquisition process of those major defense systems is an iterative, complex, 

and detailed process, which can be assumed, from the global perspective, as a risk 

management mechanism that tries to satisfy the agency needs in the most mission 

effective and resource-efficient manner. 

The historical roots of this formal acquisition process go back to the post-WW n 
era, however the process was articulated in 1972 by the Conunission on Government 
Procurement. The commission’s concept was adopted as a formal acquisition process by 
issuing The Office of Management and Budget (0MB) Circular A-109 [Ref. 2]. The 
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generalized form of the acquisition process is shown in Figure 1. The formal acquisition 
process, otherwise known as the life-cycle management process, is comprised of 
consecutive phases: namely. Requirements Generation, Concept Exploration, Program 
Defimtion and Risk Reduction, Engineering and Manufacturing Development, 
Production, Fielding/Deployment, Operational Support, and finally. Demilitarization and 
Disposal [Ref 3]. In addition to those phases or system life stages, there are decision 
points, called milestones, before entering each phase in the acquisition process. Those 
milestones are developed to ensure the program’s success throughout the system’s life. 
At tiiose milestones, the approvals by pertinent authorities to enter the subsequent phase 
are made and the exit criteria for that phase is specified in a document known as an 
Acquisition Decision Memorandum (ADM). 
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Figure 1: Traditional Acquisition Proems [From Ref. 3] 


This so-called iterative and detailed process gets started with the determination of 
a requirement or an operational need by the user community, in that context operational 
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agencies or strategic force planners, through mission needs analysis. The primary inputs 
to the mission needs analysis process are national military policy analysis, threat 
assessments for adversaries or potential adversaries, or changes in military strategy and 
doctrines. Technological improvements and innovations are also important inputs for the 
mission needs analysis, since improvements and innovations in science and technology 
may redefine how the mihtary performs its missions both in organizational and technical 
terms. It is important to state at this point that all the new or redefined Mission Needs 
Statements (MNSs) may not result in new acquisition programs to develop material 
solutions. If non-material solutions, such as organizational restructuring or process 
reengineering, are available to satisfy defined needs without sub-optimization behavior, 
then these alternatives are preferred as more cost-efficient. If non-material solutions are 
proved to be ineffective, then a new system acquisition is considered the most viable 
option. 

The historical facts and lessons learned about major acquisition programs denote 
that the success of the program is highly sensitive to correctly analyzing mission needs 
and carefully converting those MNSs into Operational Requirements Documents (ORDs). 
The gap between user-defined mission needs and formal MNSs and ORDs is filled by the 
discipline of system architecting and engineering [Ref 4]. The system engineering 
process will be overviewed in a subsequent section. The technologicah'conceptual model 
of the acquisition process is devised to refine system requirements and specifications 
iteratively, rather than by providing system-specific parameters in the beginning of the 
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acquisition process, in order to incentivize technological and industrial innovation and 
develop alternative solutions and competition as much as is cost efficient. 

After a through mission needs analysis and approval of the Mission Needs 
Statement, the decision to proceed into the Concept Exploration phase, i.e. Phase 0, is 
made and the Exit Criteria firom the Phase 0 are established. The essence of this phase is 
exploring different alternatives to develop solutions to the mission needs. In that phase a 
formal Analysis of AJtematives, usually utilizing the Cost and Operational Effectiveness 
Analysis format, are conducted, and Operational Requirements Documents are generated 
for each concept that is selected to proceed with into the next phase. Provided it is cost- 
efficient, effective, and feasible, proceeding with more than one concept into the next 
phase is encouraged, since these will provide alternatives and increase the degree of 
competition. The primary tool for this and the subsequent phase, which is Program 
Definition and Risk Reduction, is using short-term parallel contracts with the responsive 
and responsible contractors, or with Federally Funded Research and Development 
Centers (FFRDCs). 

In the Program Definition and Risk Reduction phase (PDRR), the eligible 
concepts firom the concept exploration phase are narrowed down to design approaches 
and the prospective systems are evaluated closely by cost, schedule, performance, and 
supportability parameters. System prototyping, demonstrations, and early operational 
assessments, especially in virtual environments, are the primary tools to reduce risk, 
which is inherent in any system development. The cost drivers in the life-cycle of the 
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system are identified and the cost data to support program budgeting decisions are 
developed in that phase. 

In Phase n, which is the Engineering and Manufacturing Development phase 
(EMD), the most promising, firom the perspective of performance, cost, schedule, 
supportability jfrom the PDRR phase, and the design approach, are evolved into a stable 
design. The producibility analysis of the solid design is performed concurrently, and the 
manufacturing techniques for file proposed system configuration are developed or 
maturated. The concurrent engineering approach, which will be discussed later, is 
utilized in that phase. This approach tries to evaluate design, producibiUty, and 
supportability issues concurrently, rather than iteratively. In order to test the proposed 
system’s operational capabilities, an optimum quantity of system is manufactured during 
Low Rate Initial Production (LRIP), which also helps to develop realistic manufacturing 
cost data. 

After operational testing and validation of the system. Low Rate Initial Production 
is evolved into Full Rate Production (FRP), which will incorporate any required 
modifications to the design; then system deployment starts. In this Operational Support 
phase, efforts are focused on sustainment of the system. Assessments will be made to 
evaluate the effectiveness of personnel, logistics support (e.g. spare parts supply and 
maintenance), and any potential cost-effective reliability improvements or modifications. 
At the end of the system’s economical life, which is pre-planned during system 
development, the system is disposed out of service. The disposal and demilitarization 
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activity should not be considered as only dropping the system out of inventory, but should 
be considered as group of activities that aim to execute the disposal process with miniTnal 
negative impact to the environment, in accordance with applicable laws and regulations. 

As stated in the beginning of this section, the underlying concepts of this 
acquisition methodology go back to the post-WWn era, when the major weapon systems 
are hardware-intensive and DoD has been the primary weapon technologies developer. 
But, the times have changed; now most major weapon systems are software-driven (an 
extension of the fly-by-wire-concept) and DoD is a technology integrator and user, rather 
than developer. The pace of technological innovation is very fast and difficult to keep up 
with. This paradigm shift profoundly affects the success of the formal acquisition process 
described above. Although it is not the primary topic of this thesis, the writer wants to 
briefly discuss the problems with the aforementioned acquisition process. 

First of all, the nature of software development is very different from that of 
hardware development. On the one hand, hardware development follows a linear 
development cycle, which is in parallel with the acquisition process. On the other hand, 
software development efforts are spiral rather than linear. The problem arises in the 
synchronization of these two different development patterns in one acquisition challenge. 
Therefore the acquisition strategy for software-intensive major weapon systems must be 
tailored to solve those problems. 

The other problem area is the paradox of the long cycle-time of the formal 
acquisition process versus high technological obsolescence rates. In today’s acquisition 
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environment, the average acquisition time for major weapon systems is 8 to 10 years. 
DoD has developed initiatives such as cycle-time reduction or the open systems approach. 
Although both are veiy promising in the quest to resolve the issue of technological 
obsolescence, these initiatives alone are not sufficient to solve the problem. A more 
radical approach to reengineering the acquisition process is required. Birkler, et al. 
propose an alternative acquisition process to acquire state-of-the-art technology and 
innovative systems. This process is called the dual path acquisition methodology, and is 
depicted in Figure 2. The key objectives of that so-called process are rapid development 
of new operational and system concepts, acceleration of development and demonstration 
of new concepts at system and subsystem level, and providing early provisional 
operational employment of new systems well before completion of design stabilization 
and full operational testing. The so-called dual path process is devised to work in 
conjimction with the current acquisition process [Ref. 5]. 



Figure 2: An Innovative Process Proposed by RAND [From Ref. 5] 
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Considering the deficiencies of the traditional acquisition process, DoD 
reengineered the process in May 2000. Basically, the new process separates technology 
development fi-om system development, and is devised in order to enable DoD to acquire 
innovative systems in shorter times at reasonable cost (Figure 3). [Ref. 6] Realization of 
shorter acquisition lead times is specifically emphasized in the process because of high 
obsolescence rates and proliferation of weapon system technologies. The cost, 
performance and schedule risks in the systems acquisition process have been addressed 
by promoting use of mature technologies, evolutionary requirements generation 
(achieving initial operational capability as soon as possible and developing open systems 
architectures rather than finishing the full system development phase), and developing 
cost objectives and sticking to those objectives throu^out the systems acquisition 
process. At highest level, the new process includes three phases: pre-system acquisition, 
system acquisition, and sustainment. The pre-system acquisition phase is comprised of 
concept and technology development efforts; those efforts and verification of 
technological maturity are the responsibility of the science commimity rather than 
acquisition orgamzations. Formal acquisition programs start only after the science and 
technology organizations verify the maturity of technology. The system acquisition phase 
is comprised of system integration, demonstration, manufacturing, and deployment to 
achieve Initial Operational Capability (IOC). The acquisition program can commence at 
any point before production starts, rather than following a mandatory sequential path as in 
the old acquisition process. The last phase of the system life-cycle in the new process is 
the sustaimnent phase, which comprises operations and support activities with Full 
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Operational Capability (FOC). An in-dq)th evaluation of the new process will not be 
discussed because it is beyond the scope of this thesis. 
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Figure 3: The New DoD Acquisition Process [From Ref. 6] 


B. SYSTEMS ENGINEERING PROCESS AND RELEVANT CONCEPTS 

1. Systems Engineering Overview 


Systems Engineering can be defined as 

...an application of scientific, engineermg, and managerial eflforts 
to transform an operational need into a description of system performance 
parameters and a system configuration throu^ the uses of iterative proems 
of definition, analysis, synthesis, design, test and evaluation; integrate 
related technical parameters and ensure compatibility of all physical, 
functional and software interfaces in a manner that optimizes the total 
system definition and design; and integrate reliability, maintainability, 
safety, survivability, human engineering and other such factors into the 
total engineering effort to meet cost, schedule, supportability and technical 
performance objectives. [Ref. 7] 
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An alternative definition of the systems engineering process is such that 


...an interdisciplinary approach encompassing the entire technical 
effort to evolve and verify an integrated and hfe-cycle balanced set of 
system, people, product, and process solutions that satisfy customer needs. 
Systems engineering encompasses the technical efforts related to the 
development, manufacturing, verification, deployment, operations, 
support, disposal of, and user training for, system products and processes; 
the definition and management of system configuration; translation of the 
system definition into work breakdown structures; and development of 
information for management decision making. [Ref 8] 

These two alternative definitions of systems engineering give insight into the 
fundamental characteristics of systems engineering practice, which are discussed in the 
following paragraphs. 


Systems engineering utilizes a top-down approach and views the system as a 
whole, in contrast to the bottom-up approach, which is utilized in traditional engineering 
disciplines such as mechanical or electrical engineering. The primary focus areas in the 
systems engineering process are addressing user requirements in all levels of 
development efforts, and interfaces, either subsystem level or system and beyond system 
level, which encapsulates a system-of-systems concept. The difference in approaches has 
significant effects in practice such that the top-down approach uses hierarchical 
abstraction models to ensure successful interface of the subsystems, but does not warrant 
physical realization of subsystems or components; on the other hand the bottom-up 
approach guarantees the physical realization of components or subsyste ms , but does not 
ascertain successful interface between subsystems or components of a system. However 
both methodologies are not substitutes for each other, rather they are complementary 
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methodologies in such a way that first and continuously utilizes systems engineering 
methodologies in order to ensure satisfaction of user requirements and successful 
interface between system elements, and reduce complexity and total ownership costs that 
utilizes traditional engineering methodologies to realize the existence of components or 
subsystems of a system. [Ref. 9] 

From the systems engineering perspective, it is very crucial that system 
developers understand user needs well, and develop system requirements definitions 
correctly, based upon those well-imderstood user requirements; the ultimate goal of 
system development efforts should be user satisfaction in a cost-effective manner [Ref. 
9]. The system requirements must be well defined, specified in terms of functional 
performance parameters, and be traceable throughout all levels of the sj^tem. The lack of 
understanding user requirements correctly in the initial phases of the system development 
effort may lead to very cost-intensive engineering changes in the succeeding phases of 
system development The decisions, based on perceived user needs, in early stages of 
system development efforts when the system specific knowledge is limited, determine the 
cost behavior and effectiveness in terms of both operational and logistical support of the 
system. At the same time, the ease of system configuration change decreases and the 
resource requirements for implementation of the configuration changes increases 
exponentially throughout the system life. This system development pattern is shown in 
Figure 4. 
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Figure 4: System Development Pattern [From Ref. 9] 

The Systems engineering process is a life-cycle oriented approach, which 
addresses all phases of system life from conceptual design to disposal. In traditional 
product development or engineering approaches, the emphasis has been primarily on 
system acquisition and design activities, and this approach has generally resulted in sub¬ 
optimization without considering the total life-cycle cost of the system. On the other 
hand, in the systems engineering approach the development efforts are focused on 
reducing total ownership costs while increasing overall system effectiveness. 
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Systems engineering is inherently an interdisciplinary approach and requires 
teamwork throughout all phases of the system development cycle in order to ensiue that 
all design objectives and performance parameters are addressed in an efficient and 
effective maimer. This so-called team approach resulted in the Integrated Product and 
Process Development (IPPD) technique, which will be addressed in another sub-section. 

2. Systems Engineering Process 

Although there is some agreement m academia and industry on the fundamental 
characteristics of the systems engineering process, there are many different 
methodologies available in different domains [Ref 9]. The variance in the methodologies 
comes from either the diverse backgrounds of systems engineering practitioners and 
application areas or continuous process improvement efforts. In this subsection, the most 
popular methodologies will be briefly evaluated. 

a. Generic Systems Engineering Process Model 

This generic systems engineering process model primarily reflects 
hardware system development efforts and is derived from the hardware product 
development waterfall. The process includes inputs and outputs; requirements analysis; 
functional analysis and allocation; synthesis; verification; and feedback mechanisms 
between those sub processes (Figure 5). This process model has been very successful in 
the past in developing hardware-intensive systems such as major weapon systems, but 
with the increasing percentage of software applications in system architectures, the need 
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for a different process, which will reflect a software development pattern, has been 


evident. 


Process Input 

• CkatonwNeeds^Objoeaives/ 
Requirements 

- Kfssions 

- Measures of Effectiveness 

- Environments 
— Cof»traints 
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• Output Requirements from Prior 
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• Requirements Applied Through 
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Services, Techniques 
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* Devetopment Level Dependent 
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- System/Con^uration Item 
Architecture 
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Figure 5: Generic Systems Engineering Process [From Ref. 7] 

b. Spiral Development Model 

As mentioned in the previous sub-section, this development model has 
been bom out of the need for a different process, one which will reflect the development 
pattern of software or software-intensive systems [Ref. 4]. The stmcture of the process 
reflects one of the fundamental paradigms of software engineering: The software or 
software-embedded systems must be grown rather than built, which addresses the 
evolutionary, time-phased development nature of software or software-embedded 
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systems. Basically, the spiral process prescribes developing the product baseline and 
realization of IOC as soon as possible, and evolution of the product according to the 
operational difficulties and needs experienced. It has been argued that this approach 
would dramatically reduce system development cycle-time and allow the incorporation 
state-of-the-art technologies into later versions of the system, hi fact, DoD has modified 
its traditional acquisition process to realize those objectives. The spiral process model is 
shown in Figure 6. 



Figure 6: Spiral Process Model [From Ref. 9] 
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c. V Process Model 


The fundamental concepts of this model are borrowed jfrom the National 
Aeronautics and Space Administration (NASA) Software Quality Assurance Program 
(SQAP), which was used in the 1980’s by the agency; the process is also called “technical 
aspect of project management” [Ref 10], As shown in Figure 7, the model is comprised 
of two major sub-processes, namely the decomposition and definition sub-process, and 
the integration and verification sub-process, respectively, for each arm of the V shape. 
The model is intentionally designed to develop direct correlation between both arms of 
die V shape at each decomposition level, so that once the S 3 ?stem specifications are 
determined in the left side of die V, the verification method for those ^ecifications must 
be determined simultaneously. This model is a meta-process for systems engineering 
management and requires the tailored application of the generic systems engineering 
process at each level of decomposition. 


Testing 



Figure 7: V-Process Model 


[ From Ref. 10] 
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d. Hartley-Pirbhai Methodology 

Hartley-Pirbhai methodology has been bom out of the need to solve 
problems encountered in the integration of the systems’ software and hardware elements 
in the avionics industry, it has been utilized in many real-time software-embedded system 
development efforts in different industries [Ref. 11]. This methodology is 
complementary to spiral development model, rather than an alternative systems 
engineering process and should be used concurrently with the spiral development model. 

The underlying assumption for the methodology states that both hardware 
and software components of the system are highly interrelated, and in order to 
successfully perform their intended function, they must integrate well. Based on this 
assumption, the methodology treats the system as a whole, including both software and 
hardware components, and develops system functional and architectural specifications 
through system requirements and architecture models in an integrative manner, rather 
than following different paths characteristic of traditional system development 
methodologies. In the highest level, the methodology consists of a requirements model 
and an architecture model, which define respectively, what the system should do 
(functions) and how the system should perform those functions (architecture). 

3. Open Systems Architectures 

Open Systems Architecture (OSA) has been defined as a system development 
concept “that implements sufficient open specifications for interfaces, services, and 
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supporting formats to enable properly engineered components to be utilized across a wide 
range of systems with minimal changes, to interoperate with other components on local 
and remote systems, and to interact with users in a style that facilitates portability” [Ref. 
12]. In more explicit words, OS A is a system or product development strategy that 
enables the system developers to specify modular, interchangeable, upgradeable systems 
that will be adaptable to technological innovations and changes in the user requirements 
in a resource-efficient manner. 

This system development strategy together with Single Process Initiative (SPI), 
which tries to eliminate the differences between commercial systems production 
methodologies and defense systems production methodologies, and development of 
flexible manufactunng systems are effective enablers in reducing total ownership costs 
and acquisition cycle-times for the defense systems. As a matter of fact, the introduction 
of a new major system acquisition process, which adopted a time-phased requirements 
and incremental system development methodology, makes the application of OPA an 
imperative for acquisition strategy planners. 

4. Integrated Product and Process Development Concept and 
Concurrent Engineering 

The Integrated Product and Process Development (DPPD) concept is a 
management technique that simultaneously integrates all essential acquisition activities 
through the use of multidisciplinary teams, which are called Integrated Product Teams 
(IPT) in order to optimize the design, manufacturing and supportability processes. IPPD 
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facilitates meeting cost and performance objectives from product concept through 
production and field support [Ref 13]. From the technical viewpoint, the definition 
connotes the systems engineering process, however the IPPD concept takes the teamwork 
orientation of the systems engineering process further, to include not only design and 
logistics-oriented members, but also include the budgeting and business-oriented people 
(such as contracting officers or contractor’s personnel) into the product development 
teams; the PPD concept aims to improve product-related processes by concurrently 
including design, manufacturing, and support. The latter objective of the PPD concept is 
called “concurrent engineering. ” 

The size of the PTs should be based on the nature of the system to be acquired, 
but either overcrowding or understaffing the teams may lead to undesired results in the 
rqjplication of the concept. Overcrowding may slow down the decision-making process 
in the teams and cause longer acquisition cycle-times and inefficient use of limited 
resources; whereas' understaffing the teams may lead to omission of important 
perspectives that may result in catastrophic consequences such as unsatisfied agency 
needs, program delays, or unsustainable systems. The lessons learned from the major 
acquisition programs make it imperative that the team members have adequate training 
and the required skills for effective team dynamics. The other point that deserves 
consideration is that adding new members to any system development team, especially for 
software-intensive systems, to expedite the acquisition process makes acquisition cycle 
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time longer rather than shortening it, since generally the most efficient team members are 
assigned to orientate the newcomer to the process or team. [Ref. 14] 

5. Configuration Management And Engineering Changes 

The concept of Configuration Management (CM) arises from the need to evaluate, 
and track the changes made on system specifications mandated either by changes in in itial 
requirements or technological effects, such as imavailability of required technology and 
manufactunng processes, or development of more mission-effective or cost-efficient 
parallel technologies; and to ensure the successful integration of those changes into the 
whole system configuration. CM can be regarded as an umbrella activity that manages 
the changes throughout the system life from system development efforts to sustainment. 
Before discussing the CM functions, it is helpful to overview briefly the drivers of 
configuration changes, the nature of the changes, and their effects of those changes on 
total system ownership costs. 

One of the major drivers for configuration changes during system life is a change 
in the requirements which started the acquisition program. The requirements generation 
and system engineering processes in the DoD acquisition process are structured to 
minimize substantial configuration changes in the system throu^ validation of 
requirements at all levels before beginning system development efforts. However, 
experience shows that there have generally been modifications in system requirements, 
especially in changing threat environments. The changes in requirements stem either 
from the imcertainty m mission environment or changes in the operational doctrines. The 
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new DoD acquisition process, which is overviewed in the first section of the chapter, 
adopted evolutionary requirements and open systems architectures concepts to deal with 
problems stemming fi-om this domain. However, even with adoption of those concepts, 
the application of changes in system mission needs to system requirements may prove to 
be costly, especially at later stages of system development, since mission needs changes 
directly affect capstone system requirements. 

The other family of drivers for system configuration change arises fi'om the 
system and manufacturing technology domains. The writer prefers to call these kinds of 
change drivers as technological effects that may have either positive or negative triggers 
behind them. For example, the unavailability of required system technologies or 
manufacturing technologies might lead to substitution of more mature and available ones, 
thus changing the system configuration becomes imperative. On the other hand, 
incorporation of some other parallel technologies, either to the system configuration or to 
the manufacturing process, may prove to be more mission-effective and cost-efficient 
through value engineering efforts, thus changes in system configuration become 
unavoidable. 

The main determinants that affect the cost of configuration changes are the timing 
and magnitude of the configuration change. As Figure 4 depicts, the cost of change 
increases exponentially as the system life progresses; as a rule of thumb, it requires 10 
times more resources to implement a configuration change during the production or 
sustaiiunent phases than implementation of a similar change during the sj^tem 
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development phase. The other determinant of configuration change cost is the magnitude 
of the change. The required or proposed configiiration changes may be either be local 
changes i.e. only at subsystem level that does not affect whole system behavior and does 
not require configuration changes in other levels, or global changes i.e. that require 
reconfiguration of other subsystems and the whole system for successful integration. 
However, the lessons learned show that most of the configuration changes prove to be 
latter ones, and require adjustments at different levels, especially in software-embedded 
systems. The relationship between magnitude of change and cost of change is shown in 
Figure 8. 



Figure 8: The Cost versus Magnitude of Change [ Developed by the Author] 

The function of configuration management has a dual purpose: the first being to 
ensure the realization of developed system specifications in the final product, product 
descriptions, and system-related dociunents such as technical or operational manuals; and 
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the other being to ensure successful integration of specification changes made either at 
subsystem, component, or system level into system specifications and incorporate those 
changes into system-related documents or procedmes such as system logistics support 
functions. As stated in the beginning of the sub-section, configuration management is a 
continuous activity throughout the system hfe-cycle; therefore configuration management 
functions should be performed by a formal organization within the program office and 
system modification activities, even in the sustainment phase, should be coordinated with 
that organization. 

C. SYSTEM LIFE-CYCLE COSTS AND COST AS AN INDEPENDENT 
VARIABLE (CAIV) CONCEPT. 

In this section, the hfe-cycle costing concept and its elements, and the effects of 
system rehability and irmovative business processes in systems acquisition upon system 
hfe-cycle costs will be briefly discussed. The discussion will be based on theoretical 
approaches rather than empirical studies, and is intended to build an adequate reader 
knowledge base concerning those concepts. Throughout this thesis, the terms “hfe-cycle 
costs” and “total ownership costs” will be used interchangeably. 

System hfe-cycle cost is defined as total cost to the acquiring agency of the 
acquisition and ownership of the system over its full life. It includes cost of development, 
acquisition, operation, and where applicable, disposal pR.ef. 15]. In the acquisition and 
cost estimation literature, there are many cost terms, such as flyaway costs, weapon 
system costs etc, defining some portion of system total ownership costs that may cause 
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misimderstandings for readers who are outside the acquisition community. Figure 9 
shows the relationship and hierarchy of those cost terms. 



Figure 9; Cost Terminology IFrom Ref. 16] 

As indicated in Figure 9, Design-to-Unit-Production-Cost (DTUPC) is comprised 
of basic unit procurement cost including recurring production costs, but excluding initial 
spares costs. DTUPC plus non-recuiring production costs comprise system flyaway 
costs. We^on system cost is formed by addition to flyaway costs of any item costs 
required, such as support equipment, but the initial spares costs are excluded in we^on 
system costs. Addition of initial spares cost to weapon system costs comprises system 
procuremait cost. Program acquisition cost is procurement cost plus Research, 
Development, Test, and Evaluation (RDT&E) cost and facility construction costs, if 
required, for system operation. Program acquisition cost plus system operation and 
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support, and system disposal cost, if applicable, is called system life-cycle cost or total 
ownership cost. 

As stated in the previous section, the decisions made in the early stages of the 
system development effort while there was limited system-specific knowledge, determine 
the life cycle-cost behavior of the system. However, the costs are incurred at the later 
stages of system life, they are established by system development decisions. These 
system development patterns are shown in Figure 4. One of the acquisition reform 
initiatives, which is the Cost As an Independent Variable (CATV) concept, is formulated 
to control resource commitments during system development efforts. Basically, the 
CAIV concept can be defined as developing life-cycle cost targets for file system to be 
acquired and constraining the system design decisions or trade-offs by the target cost of 
system ownership. Prior to the CAIV concept, the Design-to-Cost approach (DTC) was 
very popular in the acquisition community, but DTC approach has been primarily 
concentrated on controlling system procurement costs, rather than system life-cycle cost, 
whereas the CAIV is life-cycle oriented, which tries to optimize the entire system life- 
cycle cost rather than a portion of life-cycle cost. The difference between these two 
approaches has profound effects on system cost behavior. For example, improving 
system reliability and maintainability to optimal levels may increase the cost of system 
development efforts, which is not desirable fi-om the DTC perspective, but improved 
reliability and maintainability will, in long run, eventually decrease total ownership costs. 
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1. 


Discussion of System Life-Cycle Cost Elements 


As defined above, system life-cycle cost (LCC) or system total ownership cost 
(TOC) is total of all the costs incurred during system life. The major components of the 
systan LCC are Research, Development, Test, and Evaluation (RDT&E) costs; 
Investment Costs which include Military Construction (MILCON) costs, and Production 
and Deployment (P&D) costs; Operation and Support (O&S) costs; and Demilitarization 
and Disposal (D&D) costs. As shown in Figure 10, the distribution of those LCC 
elements throughout ^ical system life is such that: 10% of LCC is RDT&E, 30 % of 
LCC is Investment Costs, and 60% of LCC are O&S and D&D costs respectively. As it 
is clear jfrom the proportional cost element contribution figures, the highest cost driver in 
LCC is O&S costs; therefore the system developers put fecial emphasis on reduction of 
O&S costs dn-ough improving ^tem reliabilily to the extent feasible, and decreasing 
manning and logistics support requirements for the system. The “smart ship” program in 
the US Navy is good example of those kinds of efforts. The effect of design factors such 
as reliability and maintainability on LCC will be discussed comprehensively in Section D. 



Figure 10: LCC Distribution (From Ref. 16] 
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In the following sub-sections, major LCC components will be discussed and their 
cost elements will be listed briefly. 

c. RDT&E Costs 

The costs associated with system development efforts constitute RDT&E 
costs and are incurred during system development and testing efforts. The software 
component of any system actually is produced in that period since software reproduction 
costs are ignorable relative to costs incmred during software development efforts. 
Generic RDT&E Work Breakdown Structure (WBS) consists of those cost line items. 

■ Project management costs 

■ System test and evaluation costs 

■ Data collection and generation costs 

■ System engineering and integration costs 

■ Demonstration and validation costs 

■ Hardware research and development costs 

■ Software development costs 

■ Prototype manufacturing costs etc. 

b. Investment Costs 

Investment costs cover all the costs incurred to field the system to the 
operational units. We can classify investment costs into two major categories; mihtary 
construction costs (MILCON), and Production and Deployment costs (P&D). MILCON 
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costs are associated with construction requirements in order to manufacture, operate, and 
support the system throughout the system life. P&D costs refer to costs incurred for 
manufactunng and deployment of the system into the operational units. They include 
costs such as developing manufacturing equipment, production process control and 
quality assurance etc.; the recurring manufacturing costs; costs of system support 
equipment and training equipment; cost of initial spares; documentation; and the other 
costs required to make the system deployable. Generic WBS elements for Investment 
costs: 

■ MDLCON Costs 

■ Production tooling and test equipment cost 

■ Production set-up cost for lots 

■ Pre-production engineering non-recurring costs 

■ Recurring production costs 

■ Support equipment cost 

■ Initial spares cost 

■ Transportation costs 

■ Training devices costs 

■ New or modified facilities costs 

■ Warranty costs etc. 
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c. O&S Costs 

O&S costs are the total of the costs associated with operating and 
supporting the system through its operational life. As mentioned previously, the largest 
portion of the system LCC is incurred through its operational life, whereas the 
opportunity to control O&S costs is very limited in that phase of the system life-cycle. 
Generic Cost Element Structure (CES) of O&S costs is such that: 

■ Personnel (Operations, Maintenance, Training etc.) 

■ Unit level consumption (Consumable Materials, Energy 
Consiimption, Spares Replenishment, Training Munitions etc.) 

■ Maintenance Material Costs (O-level, I-level, D-level) 

■ Sustaining Support Costs (Support equipment maintenance and 
replacement. Sustaining engineering support. Software 
maintenance costs etc.) 

■ Indirect Support Costs (Persoimel Support, Installation Support) 

d. D&D Costs 

D&D costs are incurred at the end of system life, and associated with 
disposal of the system with minimal environmental effect. The increasing level of 
environmental awareness by public, restrictive environmental regulations, and security 
considerations make the appropriate disposal process an imperative. 
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2 . 


Effects of Innovative Business Processes on Total Ownership Costs 


So far, especially in section B, we have championed innovative business practices 
such as system engineering methodologies, concurrent engineering, integrated product 
and process development, and time-phased requirements approach etc. At this point, a 
pragmatic question rises in ones mind; what would be the effects of those practices on 
system LCC? Are internal rates of return (IRR) on investment for those practices large 
enough to compensate for costs related to application o 'those practices? 

From the program manager’s perspective, these irmovative practices can be 
regarded both as effective variability and uncertainty reducers and as productivity 
improvement tools throughout the system’s life. Although using group techniques, such 
as IPPD and ffTs, in any decision-making process may lengthen the decision-making 
period relative to one functional expert, the probability of erroneous decision-making that 
affects the future behavior of any system decreases dramatically utilizing the group 
process. Althou^ resource-intensive, both in terms of time and financial resources, 
application of vigorous system engineering and integration methodologies during 
requirements definition and system development studies through will pay back via lower 
system LCC with less uncertainty as the Figure 11 indicates. 
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Figure 11: Impacts of Innovative Practices on System LCC [From Ref. 17] 


D. SUPPORTABILITY ANALYSIS AND ILS CONCEPT 


As mentioned in the previous section, system O&S costs constitute the major 
portion of the system LCC; therefore the writer concluded that it would be beneficial for 
the study to explore the factors that affect system O&S costs, the methodology for 
conducting predictive supportability analysis during system development efforts (which 
help system developers make design and performance trade-offs), and the tools currently 
available to conduct consistent supportability analysis. This section of the thesis is 
organized to reahze that objective. 

The paradigm in the system development process has been changed over the years 
from a “support the design” concept to a “design for supportability” concept. In other 
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words, supportability considerations have been inputs to the system development process 
rather than post-process considerations. The impacts of the paradigm shift are shown in 
Figure 12. The paradigm shift in the process has introduced the concept of Integrated 
Logistics Support (ILS) to the system acquisition environment. The ILS concept can be 
defined as 


...a disciplined, unified, iterative approach to the management and 
technical activities necessary to integrate support considerations into 
system and equipment design; develop support requirements that are 
related consistently to readiness objectives, to design, and to each other; 
acquire the required support; and provide the required support during the 
operational phase at minimum cost. [Ref 18] 


Basically, ILS is a management function that tries to assure deployment of 
systems, not only with the desired functional performance, but also with expeditious and 
economically optimal supportability. 



Figure 12: Impacts of Paradigm Shift in System Design [From Ref.l8] 
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1. Design and Organizational Factors Which Affect System 
Supportability and Availability 

The factors that affect system supportability can be classified into two interrelated 
categories; system design factors, which are inherent in the system design, and 
organizational factors that define the environment in which the system is operated and 
supported. Some of those design factors can be stated as rehability, maintainability, 
usability, and transportability; whereas organizational factors address the capacity and 
capabilities of the legacy organizational structure into which the system would be 
deployed, such as maintenance and supply organizations and their respective capabiUties, 
operator and technician training mediums, or available transportation modes etc. As 
stated previously, those factors interact each other, and the result of this interaction can be 
regarded as operational availability (Ao). Basically, operational availability is the 
probability that a system or equipment will be available to operate satisfactorily under 
stated conditions in the actual environment when called upon. System Ao has been 
formulated as [Ref 19]: 

Ao ~ I+downtime), 

where uptime corresponds to Mean Time Between Maintenance (MTBM) and downtime 
corresponds to Maintenance Downtime (MDT), which includes Mean Maintenance Time 
(MMT), Logistics Delay Time (LDT), and Administrative Delay Time (ADT). Capacities 


37 



of relevant logistics organizations such as Cycle-Time (CT) and Throughput Rate directly 
affects LDT, and therefore Ao. 

In following sub-sections, the design and organizational factors and their 
interactions that affect system supportability performance will be overviewed briefly. 

a. Reliability and Spare Parts Determination 

Reliability (R) can be defined as the probability of satisfactory 
performance for a system or product in a given period of time when used under specified 
operating conditions. As stated in the definition, system reliability has four elements: 
probability, time, satisfactory performance, and specified operating conditions. 
Satisfactory performance parameters, and operating conditions must be specified clearly 
in system ORD documents. The determinants of system reliability are system failure rate 
(>.), which is an inherent system design characteristic, and operating time (t). The 
reUability behavior of the system fits negative exponential distribution as long as Mean 
Time Between Failures (MTBF) of the system is constant during operational period, and 
expected reliability of the system at its operational life can be calculated by following 
equation: [Ref. 9] 

R{f) = e-^ 


38 



When there is more than one system in any operational unit, the unit 
system reliabiUty (composite reliability) can be calculated by inclusion of the total system 
number (k) in the above formula: 

System failure rate (>-) is the reciprocal of MTBF, and for some hardware 
systems the behavior of X throughout system life is called the “bath tub curve” which is 
shown in Figure 13. As stated in Figure 13, X is assumed to have a constant value during 
operational period of the system. However for software applications, X behaves quite 
differently because of continuous software maintenance, i.e. bugging and debugging 
efforts (Figure 14). Overall system reliability is a function of the reliabilities’ of 
subsystems and components, in other words the system configuration determines overall 
system reliability. From a rehabihty perspective, system components can be integrated in 
parallel or serial forms; parallel integration enables the system developers to increase 
system reliability through increased redundancy in the system. The analytical tools that 
help evaluate system reliabihty during system development efforts are Failure, Mode, 
Effects, and Criticality Analysis (FMECA); Fault Tree Analj^is (FTA); critical useful life 
analysis; the stress strength analysis; and reliability growth analysis. In depth discussion 
of those analytical tools is beyond the scope of this study. 
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Figure 13: Hardware Component Failure Rate Behaviors [ From Ref. 18] 
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Figure 14: Software Components Failure Rate Behavior [ From Ref. 9] 

The number of system spare parts needed for the sustainment of the 
system is determined by the composite reUabilities of system components or subsystems, 
system operational period, and desired spares availabihty requirements. Spares 




availability requirements indicate the probability of spares’ availability when they are 
needed. The relationship between those parameters is indicated in the following formula: 


n=5 


iJC-lni?)" 

nl 


where S is the number of spare parts in the stock; R the composite rehability; and P is the 
probability of availability of the particular item’s spare in stock when needed. The 
probability distributions derived from this formula fits Poisson distribution with mean 
value of - InR, i.e. k*A,* t, as long as MTBF for the specified system or components 
follows exponential distribution. When determining spare numbers at unit level for a 
particular subsystem or component; first the desired protection level, that is P in above 
formula, and the operational period must be specified. The length of the operational 
period, t, depends upon different parameters such as stock replenishment period for 
expendable items, or Turn Around Time (TAT) for repairable items. Given the required 
parameters; protection level (P), and composite factor (k*^* t), we can use cumulative 
Poisson table in order to determine the required number of spares for a particular 
component or subsystem. However, if large numbers of systems are involved in the 
spares determination process, the Poisson values approach to Normal distribution values 
as the result of tire central limit theorem. In flie cost estimation model, the spare parts 
cost will be calculated by this theoretical approach. 

The system reliability is an important parameter that affects system O&S 
costs through spares requirements, maintenance actions, and the determination of the total 
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number of systems to be acquired in order to guarantee a certain number of systems are 
operationally available. The theoretical relationship between system reliability and TOC 
is depicted in Figure 15. As is clear from the Figure 15, the improvements in system 
rehability to the feasible extent, dramatically decreases system LCC; however pushing the 
envelope for system reliability beyond feasible technological levels may require huge 
commitments for R&D activities that the costs savings from improved reliability may not 
offset those commitments, so the system LCC goes up. 



Figure 15: System Reliability and LCC Trade - Off [From Ref. 15] 
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b. Maintainability 

Maintainability refers to the ease, accuracy, safety, and economy in 
performance of maintenance actions required to sustain the system during the operational 
use, and is an inherent characteristic of system configuration. One of the objectives in the 
systems engineering process is to develop a system or product that can be maintained 
effectively and safely, in the least amount of time, at least cost, with a minimum 
expenditure of resources (i.e. people, materials, test equipment, and facilities), without 
adversely effecting the mission effectiveness of the system. System maintenance 
requirements are derived firom the system Maintenance Concept (MC), which is based on 
the system ORD. The system MC broadly defines levels of maintenance, repair policies, 
organizational responsibilities for maintenance actions, logistics support elements of the 
system, effectiveness requirements for system support, and environmental conditions. 

All maintenance actions pertaining to a system can be broken into two 
general categories: corrective maintenance and preventive maintenance actions. 
Corrective maintenance actions refer to unscheduled maintenance actions performed to 
restore the system to a specified level of performance as a result of a failure. Preventive 
maintenance actions refer to scheduled maintenance actions performed to retain a system 
at a specific level of performance by providing systematic inspection, detection, 
servicing, or the prevention of impending failures through periodic item replacements. 
Preventive maintenance actions serve to keep the system in the inherent reliability 
performance level, rather than improving system rehability. Similar to hardware systems; 
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software maintenance actions are broken into two categories: adaptive maintenance and 
perfective maintenance. Adaptive maintenance refers to the continuing process of 
modifying software in order to make it compatible to changing requirements in the data or 
processing environment within the original architecture, whereas perfective maintenance 
refers to software modification efforts in order to enhance its perfonnance through 
architectural evolution. 

System maintainability is assessed through maintainability metrics, which 
can be classified into three categories: maintenance fi-equency metrics, maintenance 
elapsed-time metrics, and maintenance cost efficiency metrics. Maintenance fi-equency 
metrics are: Mean Time Between Corrective (Unscheduled) Maintenance (MTBMu), 
which is equal to MTBF on average for stable systems; Mean Time Between Preventive 
(Scheduled) Maintenance (MTBMs); and Mean Time Between Maintenance (MTBM), 
which is average time between all maintenance actions, calculated by the following 
formula. 


MTBM=-^ -^- 

/mTBMjj /MTBMs 

Maintenance elapsed-time metrics refer to the time spent during 
performance of maintenance actions. Mean Corrective Maintenance Time (Met) is the 
average time required to perform corrective maintenance actions, whereas Mean 
Preventive Maintenance Time (Mpt) refers to average time required to perform 
preventive maintenance actions. Mean Active Maintenance Time (M) is average elapsed 
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time required to execute preventive and corrective maintenance, and calculated by the 
following formula in which the “X,” and “fpt” refer to failure rate and scheduled 
maintenance rate, respectively: 

X+jpt 

Maintenance cost efficiency metrics refer to the cost part of maintenance 
actions and include hoth labor costs and material costs. Although there is no standard 
metric for maintenance cost efficiency; the most useful of those metrics are: average 
material cost for per corrective maintenance action, average material cost for per 
preventive maintenance action, job skill requirements for maintenance categories at each 
maintenance level etc. 

The enabling methods and tools utilized to develop, eiihance, and test the 
maintainability performance of the system under consideration are: Reliability-Centered 
Maintenance (RCM); corrective vs. preventive maintenance trade-off analysis; repair vs. 
discard analysis; Level of Repair Analysis (LORA); Fault Tree Analysis (FTA); 
maintenance task analysis; and maintainability prediction techniques. In depth discussion 
of those methods and tools are beyond the scope of this study. 

c. Usability 

Usability refers to hu m an interface with system, and is a determinant of 
system mannin g costs. Usability requirements for the system should be specified in the 
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system ORD, and should reflect the anthropometrical, psychological, and psychomotor 
properties of the prospective user population. The general objective in addressing 
usability requirements in system design is to establish system design criteria that will 
promote simplicity in operation and maintenance to the extent possible, in order to 
minimize personnel training costs; labor costs; probability of personnel induced system 
failures, and accidents, so that the system LCC can be minimized. 

The most important usability metrics for any system are total number of 
personnel required to operate the system, required personnel skill levels, training 
requirements, human-induced failures and accidents, and the quantity of system-induced 
health problems in the personnel. 

d. Transportability 

Transportability of a system addresses the requirement for the system, 
subsystems or components to be transportable in effective and efficient manner within 
available transportation modes and vehicles, i.e. highway transportation, airway 
transportation, or water transportation; and is directly related to system dimensional and 
weight parameters. System or subsystem transportation initially affects system LCC in 
the Production & Deployment Phase, at which the acquired systems are deployed to their 
luiits. 


During the sustainment phase of system life-cycle, transportability 
performance is one of the system attributes that affect the O&S costs. The 
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transportability effect during sustainment phase has two dimensions: the first dimension 
refers to system operating costs through energy efficiency if the system is self propelled, 
and deployment of the system to operational sites etc.; and the second dimension refers to 
system support costs throu^ material transportation costs for system support 
requirements. System transportability performance requirements must be specified 
system ORD, and must be integrated with system maintenance concept and Integrated 
LxDgistics Support Plan (ILSP). 

e. Organizational Factors 

Organizational factors in supportability of the system refer to the legacy 
logistics infi-astructure throughout all levels of the support environment in which the 
system is supposed to operate and be supported. Logistics infrastructure includes the 
procedures, processes, and people associated with logistics support as well as the physical 
resources such as support facilities, and equipment. 

Systems’ ILSP must be developed in such way that promotes efficient and 
effective utilization of the support infirastructure. The legacy logistics support 
infrastructure should be evaluated to realize improvements that enable reductions in 
system support costs. One area of interest that enables the PMs to reduce support costs 
and increase system availability without investing in additional numbers of systems or 
system spares (in order to meet operational readiness goals), is legacy organizational 
procedures for logisticss support. As stated previously, operational availabihty could be 
increased by reducing MDT, whose main elements are active maintenance time (Mt), 
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ADT, and LDT. ADT and LDT are directly related to organizational procedures or 
processes in the relevant logistics organizations. By improving those procedures and 
processes, one can reduce ADT and LDT for any system, and eventually increase system 
operational availability. For instance, changing service discipline from First In First Out 
(FIFO) to Shortest Path Method (SPM) in any maintenance organization can dramatically 
reduce average Cycle Time (CT) or Turn Around Time (TAT) for diat organization. 

2. Supportability Analysis Process 

After briefly review-ing the factors that affect system O&S costs, it seems helpful 
to discuss supportability analysis which helps evaluate the system throughout its 
projected life. Supportability analysis is a sub-process within the systems engineering 
domain than rather being a separate entity in system acquisition process. 

By defimtion, supportability analysis is an iterative process by which the logistics 
support necessary for the system under consideration is identified and evaluated within 
the concept of ELS. The objective of supportability analysis is to aid in the initial 
determination and establishment of supportability criteria as an input to design; aid 
evaluation of various design alternatives; aid in the identification, provisioning, and 
procurement of various elements of maintenance and support; and aid in the final 
assessment of system support infi-astructure throughout the sustainment phase. [Ref. 18] 

The supportability analysis is a continuous effort through system life. However 
the dq)th of the analysis and analysis tools vary at different stages throughout life-cycle 
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stages, depending upon the purpose of the analysis. Basic processes of supportdiility 
analysis are problem identification and needs analysis; selection of the analysis approach; 
establishing evaluation criteria; selection of appropriate analysis techniques; model¬ 
building and data collection; evaluation of alternatives using the model; and analysis of 
results. 


The analysis tools utilized during the performance of supportability analysis are 
briefly mentioned in previous subsection in the context of their relevant supportability 
factors. 


49 



THIS PAGE IS INTENTIONALLY LEFT BLANK 


50 



in. COST ESTIMATION 


Cost estimation can be defined as a process in which the financial resource 
requirements, which are required for developing, manufacturing, fielding, operating, and 
sustaining a system, are explored either for budgeting, programming, and fimding 
purposes, or analysis of system eflFectiveness and analysis of alternative system designs. 
Cost estimating is a recurring activity throughout system life rather than a one-time 
activity during the system acquisition period, and generally the quaUty of the estimates 
increases as the program moves through the phases of system life-cycle since the level of 
uncertainty decreases. 

The available methodologies for cost estimation are classified as the analogy 
approach, parametric techniques, the engineering approach, extrapolation from actuals, 
and the expert opinion approach; those techniques will be discussed comprehensively in 
the following section. Regardless of the methodology employed, there are some 
prerequisites in order to develop quahfied cost estimates. First, all the relevant costs 
should be included into the cost elements of the system, which refers to completeness of 
the estimate. Second, the methodology employed in order to develop a cost estimate 
must be suitable to circumstances such as availability of data, and the purpose of the 
estimate etc., and must consider the differences with analogous systems’ cost data in 
technology, and socio-economic conditions (which refers to reasonableness of the 
estimate). Finally, the assmnptions upon which the cost estimates are based and cost 
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estimation documentation must be supportable by the facts, be consistent within then- 
own context, and be valid (which refers to consistency of the estimate). 

The quality of cost estimates developed for any system is very important since all 
the resource allocation decisions, and systan effectiveness evaluations are based on those 
estimates; and as it was stated previously, the cost estimate for the system under 
consideration must be updated throu^out the system life-cycle in a way t hat reflects 
future costs based on the current status of the program, and identify cost-drivers. 

A. COST ESTIMATION TECHNIQUES 

hi this subsection, the cost estimating techniques, the relationship of those 
techniques to system life-cycle, and their effectiveness will be discussed. As pointed out 
in the previous section; the available cost estimating techniques are the analogy approach, 
parametric estimating, the engineering approach, extrapolation J&om actual, and the expert 
opinion approach. 



-OBsmifMATxmiTr . . » 



Figure 16: Cost Estimation Techniques Utilization through System Life [From Ref. 16] 
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All of those techniques are not mutually exclusive; they can be utihzed 
concurrently in order to verify the cost estimate. However, there are limitations such as 
unavailability of data to develop detailed estimates when utilizing the engineering 
approach and the extrapolation from actuals technique. Figure 16 depicts the utilization 
of these techniques throughout system life-cycle. 

Three of those techniques, the analogy approach, parametric estimating, and the 
expert opinion technique (which is also known as the round table technique), generate 
gross estimates rather than detailed estimates. The engineering approach and 
extrapolation from actuals generate detailed estimates for the system under consideration. 

The application of the appropriate estimating technique is a very important 
determinant for the quahty of the estimate; the appropriateness of the technique depends 
on the purpose of the estimate, phase of the program, and availabiUty of data resources. 
The required level of effort in order to develop a cost estimate increases exponentially as 
the level of detail in the cost estimate increases. All of the estimating techniques, except 
for the expert opinion approach, utilize mostly quantitative techniques, while the expert 
opinion approach relies on the subjective evaluations by the experts who are asked to 
estimate probable costs. In essence, the analogy approach also utilizes qualitative and 
quantitative techniques concurrently, since adjusting data for the analogous system 
requires some subjectivity. 

Presumably, all of those techniques originated from hardware-intensive system 
development efforts, but as the weapon systems get more software-intensive, i.e. 
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embedded weapon systems, those techniques need adjustments in ways that would reflect 
the inherent characteristics of software development efforts. Relative to hardware 
systems, software-intensive S5^tems are more complex, non-linear in nature, and the 
metrics or parameters of software are abstract and harder to imderstand. 

In the following sections, the cost estimating techniques will be discussed 
comprehensively. 

1. Analogy Approach 

The analogy approach in cost estimation utilizes the cost data of similar systems 
and develops a gross cost estimate for the system irnder consideration. The method 
includes a judgment process in which the similarities and differences between comparable 
systems, and their cost impacts upon the new system, are evaluated. Based upon the 
results of his/her judgment, the cost estimator develops a gross cost estimate for the new 
system. 


As the name of the technique indicates, the comparable systems are not identical, 
rather they are similar and therefore the apphcation of the method requires some 
adjustments to accormt for differences in technology, system architecture, production 
methodology, technical performance variances and capabilities, and programmatic 
differences such as acquisition schedule, acquisition strategy, and socio-economic 
conditions. 
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Since this method requires subjective evaluations by the cost estimator, the level 
of uncertainty in the estimation is very hi^, and the quality of the estimate is highly 
sensitive to the experience of the cost estimator. In order to make the judgment process 
more reliable, the cost estimator consults with the engineers, logisticians, and other 
technical experts related to systems under consideration, and develops costs estimates 
based upon feedback from those frmctional areas of expertise. 

Although the analogy method includes a high level of uncertainty, this method is 
useful dining the early phases of the system acquisition process because of the 
unavailability of cost behavior data to develop more accurate estimates for the new 
system and thus assess its practicality. 

2. Parametric Approach 

Parametric cost estimating is a quantitative technique that uses statistical analysis 
methods in order to develop a cost estimate, and develops Cost Estimating Relationships 
(CER) using system physical or performance characteristics, i.e. system parameters. The 
basic assumptions of parametric estimating are: the cost is a function of system 
parameters, parameters are statistically independent variables, meaningful CERs can be 
developed using a cost and performance database comprised of similar systems, and the 
historic cost relationships derived from the cost performance database is valid for the new 
system. 
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In this technique, estimating relationships using system parameters such as 
weight, power, speed, frequency, and thrust etc. are used to predict system cost;and the 
regression analysis is the fundamental tool for developing CERs. The parametric 
estimation procedure consists of statistically fitting a line or function to a set of related 
historical data and then substituting the appropriate parameter of the new system into the 
resulting equation. The data used to derive the CERs should be adjusted against 
inflationary effects, other programmatic circumstances, and technological differences. 

This method is generally used during system life-cycle phases prior to FRP; it is 
used when system performance parameters are mature, but the design parameters are not. 

3. Engineering Approach 

The engineering method, which is also known as the “bottom-up” method, is the 
most detailed and time-consxuning of all the cost estimating methodologies. However, 
the increased expense of this method is generally not justified by its significantly greater 
accuracy, since individual errors in each Work Breakdown Structure (WBS) element tend 
to produce a large error in the overall cost estimate. 

Basically, in this method, the cost figures are developed for the lowest level WBS 
elements, i.e. component level, from either actuals or by utilizing the estimation methods 
described in this section, and then the figures are summed up through the upper levels of 
the WBS m order to develop a system-level cost estimate. The adjustments are made for 
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non-material cost elements such as quality assurance, system integration, and program 
management efforts, based on historical cost factors for the similar programs. 

Although it seems very consistent and objective, this method also has some level 
of xmcertainty just like all of the estimating methods. The uncertainty results either from 
individual errors made at lower levels of WBS, as stated previously, or from 
unprecedentedly complex system integration efforts. System integration reqrxires much 
more than merely putting the components or subsystems together to form a system. This 
method can be utilized after the system design is stabihzed and the system WBS is clearly 
defined. 


4. Extrapolation Approach 

The Extrapolation technique uses the actual costs incurred during the previous 
production of the same system, i.e. prototype recurring costs or low-rate initial production 
recurring costs. 

This method seems the most reliable cost estimation method for the system under 
consideration; however the data required for extrapolation is available only after LRIP of 
the system is performed, and requires some adjustment for different kinds of reasons. 
First of all, the system may require some modifications prior to FRP commencement due 
to operational test results, so the system may differ from prototypes or LRIP models in 
some aspects, and the cost impact of this difference might be greater than anticipated. 
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Therefore, the cost analyst should consider those differences and their cost impacts on 
stabilized models. 

The other need for adjustment stems from production methodology differences 
between prototype or LRP and FRP. Prototype production is rather a craft type 
production in which the hi^er level engineers or technicians are deeply involved in 
manufacturing process. Production methodologies and material costs are not yet 
optimized and the capitalization of the learning curve effect is not possible since there are 
no standard procedures. The quantities to be manufactured are so small that the average 
umt cost for prototypes or LRIP umts are substantially higher than the average xuiit costs 
for future FRP muts. On the other hand, during FRP, the production process is more like 
an assembly line in which the optimal levels of employee mix have been estabhshed, 
manufacturing methodologies are standardized, and optimal material supply systems have 
been developed. The end result of those improvements is substantially lower average unit 
costs through mmimization of labor, material, and overhead costs relative to prototypes or 
umts. The cost analyst should also consider those cost unpacts in performing 
extrapolation for the future cost estimates. 

5. Expert Opinion Approach 

Expert opinion, which is also known as “round table” method, involves 
qualitative approaches to the estimation of costs related to the system imder 
consideration. This method heavily relies on the subjective evaluations of domain 
experts, such as software engineers, logisticians, or mechanical engineers etc.; is 
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generally employed when developing cost estimates for systems or research projects 
which are very innovative, and there is no previously developed analogous system or 
similar research. Especially in the software domain, where technological innovation rates 
are very high, and the products are inherently complex, abstract, and unique, the 
evaluations of software experts are the foimdation of cost estimating. 

Since the method involves the subjective evaluations of the domain experts, the 
level of imcertainty is very high. The critical factor that derives the reliability of the 
estimate is choosing credible, experienced, and knowledgeable experts. The other 
appropriate measures for increasing the reliability of the estimates are consulting with 
more than one expert in any domain, encouraging the experts to develop weighing scales 
for the cost-drivers, and asking for ranges with estimated variation rather than point 
estimates. 

B. COST ESTIMATION TOOLS 

This section of the study will discuss the auxiliary techniques and methods which 
enable cost analysts to enhance robustness, reliability and accuracy of their cost estimates 
which were developed by utilizing any or a combination of the basic methods described 
m the preceding section. The author of this thesis prefers to classify those methods imder 
the domain of cost estimation tools, since those methods metaphorically can be found in 
the toolbox of the cost analyst and are independent of the basic technique or techniques. 
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Those tools are: learning curve analysis, which is mostly relevant to recurring 
production costs; cost uncertainty analysis, which is related to risks involved in the 
developed cost figures; and sensitivity analysis, which is related to trade-off issues, 
“what if’ questions for the system’s technical, programmatic parameters, and their cost 
impacts on LCC under different scenarios. In the following subsections, those tools will 
be discussed in detail. 

1. Learning Curve Analysis 

Learning ciirves describe the empirical relationships between output quantities 
and certain input quantities, especially in recurring production activities where the 
learning inducement improvement is present [Ref. 20]. A learning curve depicts the 
concept that the cumulative average unit cost, or unit cost of the item manufactured, 
decreases in a systematic pattern as the quantity of production increases. The relationship 
between the production quantity and the cost of the systems produced is formulated such 
that the unit cost or cumulative average cost of the system decreases by a common 
percentage as the quantity produced doubles. There are many models developed for 
application of this concept, but the most popular one is the log-linear model, which is 
depicted in the following paragraph. In the formula; Yn represents the cost of the N-th 
umt, A represents the theoretical cost of the unit, and B represents the slope coefficient 
of the learning curve. 


r^=AN^ 
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The slope coefficient of the learning curve can be calculated by following 


equation. 


B = 


\n{LEARNING_ SLOPE) 
ln2 


The learning curve theory is based on a simple principle of human nature: people 
leam from experience, and the learning phenomenon increases people’s productivity and 
efficiency. There are two factors that constitute learning phenomenon in the production 
environment: one being the learning in literal sense on the part of labor force, and the 
other being enterprise-wide business process improvements derived firom lessons learned 
from practice. 

The cost impact of learning curve theory during system hfe cycle can be very 
substantial on system production costs, especially when a large number of systems are 
required to be manufactured; this cost impact should be factored into the production cost 
projections for the systems under consideration. On the other hand, there is a negative 
relationship between the employee turnover rate and achieved learning within any 
organization, therefore when factoring the cost impact of the learning phenomenon into 
system production cost estimates, the cost analyst should make adjustments for employee 
turnover rate. 

The learning curve theory may have also have an impact on system LCC during 
the sustainment phase in which system maintenance actions are performed. However, in 
general practice, the system maintenance costs are estimated by the mean maintenance 


61 



time parameter, which is developed by statistical experimentation methods and therefore 
the learning phenomenon is indirectly factored into calculation of mean maintenance 
times. 


As an extension to the learning curve model, the log-linear model described 
above, the rate adjustment model is also used in industry. The rate adjustment model 
basically assmnes that in addition to learning rate, the production rate, which defines the 
quantity to be produced in certain period, also affects production costs systematically. 
The relationship formulated at following formula in which the “Q” represents the 
production rate, “C” represents the rate coefficient, and the other variables representing 
the same values in the learning curve formula. 

Similar to the learning curve theory, the rate coefficient, C, can be calculated by 
the following equation. 

^ \n{RATE _SL0PE) 

ln2 

2. Cost Uncertainty Analysis 

In general, cost uncertainty analysis is the process of quantifying the cost impacts 
of the uncertainties associated with cost estimation methodologies and the cost data 
utilized in developing cost estimates. These imcertainties in cost estimation arise either 
from mherent uncertainties in the data collection and es timatin g methodologies involved 
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in the estimating process, or from imcertainties in program and system parameters. 
Economic uncertainties that influence the cost of technology, the labor force, geopolitical 
policies, the validity of the assumptions made by the cost analysts such as the amount of 
software reuse and integration efforts, further contribute to the cost imcertainty inherent 
in system development efforts. The imcertainties in program and system technical 
parameters and their cost impacts can be also assessed through sensitivity analysis, which 
will be discussed in the following subsection. [Ref. 21] 

Because of the aforementioned imcertainties, the realization the probability of a 
point estimate developed through the cost estimation process is literally almost zero. 
Therefore the cost figures are stated in tihe form of statistical distribution functions based 
on the statistical analysis of the available cost data. For instance, the cost figures 
developed through regression analysis application are used in the form of a normal 
distribution function with a standard deviation rather than a point estimate, such as 
expected regression value. 

As discussed previously, the system cost breakdown is comprised of many cost 
elements and sub elements such as manufacturing costs and its sub-elements etc., and the 
overall system cost is estimated throu^ the summation process of those relevant cost 
elements. This summation process affects cost uncertainty substantially and in such a 
way that the variability decreases and the overall cost estimate approaches a normal 
distribution function regardless of different distribution functions used in the sub-element 
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cost ranges. This tendency towards normal distribution is called “central limi t theorem” in 
statistical science [Ref. 21]. 

Simulation is the primary method for conducting imcertainty analysis, and the 
Monte Carlo simulation technique is a successful tool used to develop cost figures based 
on defined uncertainty parameters. Basically, the Monte Carlo simulation produces 
random numbers according to the statistical distribution functions defined in the system 
cost elements, repeats this process xmtil the desired number of trials is achieved, and gives 
the expected value with statistical central tendency metrics such as standard deviation, 
mean, mode, and fi'equency. 

The benefits of cost uncertainty analysis for the decision-makers can be classified 
into three categories: establishing cost and schedule risk baseline, determining cost 
reserve, and conducting risk reduction trade-off anal 5 ^es. 

Baseline cost and schedule probability distributions for a given system 
configuration, acquisition strategy, and cost-schedule estimation approach provides 
decision-makers visibility into potentially high-payoff areas for risk reduction initiatives, 
and an assessment of the likelihood of achieving the budgeted cost for a given schedule. 
Cost uncertainty analysis also provides a basis for determining cost reserve as a function 
of the uncertainties specific to a s 3 Astem through an assessment of maximiim cost 
magnitude and its likelihood. Besides those benefits, the cost uncertainty analysis can be 
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conducted in order to assess the effectiveness of alternative risk reduction strategies for 
reducing system cost and schedule risks and their respective payoffs. 

3. Sensitivity Analysis 

In general, sensitivity analysis is the process by which the cost impacts or 
marginal effects of variations in the program input parameters such as system technical 
performance and supportability requirements, or in the program schedule, are examined. 
Sensitivity analysis is also known as “what if’ analysis. In order to conduct meaningful 
sensitivity analysis, sound relationships between system or program parameters and 
system LCC must be developed as a prerequisite. 

Sensitivity analysis differs from cost uncertainty analysis in such a way that cost 
xmcertainty analysis is performed within the given program and system parameters, 
whereas the sensitivity analysis is performed through playing with given input parameters 
of the system or program. Basically, sensitivity analysis is conducted by changing one of 
the input values of the program or system while holding odier parameters constant, and 
assessing the cost impact of this change on the LCC of the system. However, those two 
methods, uncertainty analysis and sensitivity analysis, are complements to each other 
rather than alternatives. 

Primarily, sensitivity analysis is conducted during system development efforts in 
order to perform life-cycle cost-oriented design trade-offs, which aim to optimize system 
design in terms of both performance effectiveness and cost efficiency. 
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C. COST ESTIMATING PROCESS 


The generic cost estimation process includes these activities: definition and 
planning, data collection and analysis, estimate formation, review and presentation, and 
developing final cost estimate and documentation. [Ref. 22] 

1. Definition and Planning Activity 

Definition and planning activity includes the identification of the cost estimating 
purpose; definition of system parameters, ground rules, and assumptions; selecting 
appropriate estimating approach; and formation of the cost estimating team. 

Identification of the purpose of the cost estimate directly affects the scope, level of 
detail of the estimate, selection of the estimating technique, and the type of cost 
estimation documentation required. As stated previously, system cost estimation studies 
are conducted for two main reasons: budget formulation, i.e. developing baseline for 
resource allocation decisions, and comparative studies such as system effectiveness 
evaluations and evaluation of design alternatives etc. 

Definition of system parameters, ground rules, and cost assumptions provides a 
basis on which the sj^tem cost will be estimated. System parameters include the physical 
or performance characteristics of the system, whereas ground rules and assumptions 
include acquisition strategy, program schedule, statements and conditions that affect or 
are assumed to affect system LCC, and assumptions for the WBS elements. 
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As stated before, the quality of the estimate is directly affected by the 
appropriateness of the estimating approach utilized, and the selection of estimating 
approach depends upon the purpose of estimate, availability of data, and time. In 
definition and planning activity, the cost analyst tries to choose the best approach 
depending upon the constraints mentioned previously. 

The cost estimating process requires teamwork rather than one-man activity; 
therefore the cost analyst should determine the appropriate mix of experts, depending on 
selected estimating approach, and Cost Analysis Requirements Description (CARD) 
document, which is developed during description of system parameters, groimd rules, and 
assumptions. The guiding principle in building a cost analysis team should be the IPPD 
concept, discussed in the previous chapter. 

2. Data Collection and Analysis 

In this phase of the cost estimation effort, the data required for the cost estimate 
is collected from alternative data resources such as Defense Acquisition Executive 
Summary (DAES) reports. Selected Acquisition Reports (SAR), price indexes, or cost 
factors handbooks etc. The type of required data depends on the selected estimation 
approach; however it includes not only cost data, but technical and programmatic data for 
the system as well. 

The collected data are generally in raw form and require some adjustment process, 
which is also known as the normalization process. In the normalization process. 
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inflationary and other programmatic effects such as quantity, technology changes, or 
differences in data collection methods are stripped off in order to make the data elements 
compatible with each other. For instance, all then year or different constant years cost 
figures are converted to common constant year figures. Then the normalized data is 
analyzed for identification of statistical properties. 

3. Estimate Formation 

Estimate formation is the process by which the chosen estimating approach is 
applied and the cost model for the system is developed according to the assumptions and 
ground rules determined in the defimtion and planning phase. The normalized data and 
the results of data analysis in the previous phase are used to develop CERs, cost factors, 
analogies, and learning curves, and then those relationships are applied to the program 
under consideration. 

As the final step in the estimate formation phase, the developed cost figures are 
spreaded fiscally throughout the program and converted to then year cost magnitudes if 
the purpose of the estimate is budget formulation. However, if the purpose of estimate is 
to conduct comparative studies, such as effectiveness evaluation or evaluation of different 
design approaches, then fire most useful method is to convert the cost figures into present 
value using appropriate discount rates. 
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4. 


Review 


In the review phase: the robustness, completeness, reasonableness, and realism of 
the estimate are tested through sensitivity and uncertainty analyses. As was mentioned 
above, the sensitivity analysis is conducted through playing with cost model input 
parameters such as system parameters or other programmatic parameters. In imcertainty 
analysis, both the program cost and schedule risks within the program and the system 
parameters are assessed; and the effectiveness of alternative cost and schedule risk 
reduction initiatives are evaluated. There is a feedback loop between the definition, 
planning, and review phases. The feedback enables cost analysts to test different system 
and program parameters throu^ sensitivity analysis, and the cost and schedule 
probability assumptions through imcertainty analysis. 

5. Documentation 

Documentation refers to consistency of a cost estimate, and is rather a continuous 
activity throughout the estimation process although it is discussed here as if it were the 
last step in the estimation process. 

As it is evident fi'om the preceding discussions throu^out the chapter, the cost 
analysis process requires judgments and assumptions by the cost analysts on the team. 
All those judgments, assumptions, and their rationale must be supported by factual 
information throu^out documentation activities. 
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IV. ATACMSIALCC COST ESTIMATION 


A. SYSTEM DESCRIPTION 

1. Mission 

The Army Tactical Missile System (ATACMS) Block lA was developed to satisfy 
the Army’s urgent need for a long-range weapon that operates in near all-weather, day or 
night conditions. The ATACMS Block lA is capable of effectively engaging hi^ value 
targets at ranges well beyond the capability of cannons, rockets, and the Army ATACMS 
Block I missile system, and is required to be efficiently transportable widi available 
transportation modes; air, rail, and truck. The ATACMS lA will effectively attack and 
defeat Surface-to-Surface Missile (SSM) \mits. Air Defense (AD) units. Command, 
Control and Co mmuni cation (C3) sites, and helicopter Forward Area Rearming and 
Refueling Points (FARRPs) of the hostile force. 

The ATACMS Block lA will be fired fi'om a modified M270A1 Multiple Launch 
Rocket S)^tem (MLRS) Larmcher and will be deployed within the ammunition loads of 
corps MLRS battalions and division artillery MLRS batteries. The corps MLRS battahons 
will provide fires for General Support (GS) of the corps, and GS-Reinforcing (GSR) to 
selected divisions. Divisional MLRS batteries with ATACMS lA will provide GS to 
divisional force. 
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2 . 


Sub System Functional and Performance Descriptions 


fl. Guided Missile Launch Assembly (GMLA) 

(1) Guidance and Control Section: The Guidance and Control 
Section is formed by Improved Missile Guidance Set (MGS) which employs GPS 
corrections and provides all navigation, guidance, autopilot, and communications 
functions for the ATACMS lA missile. Continuous determination of position, attitude, 
and motion are provided by the inertial sensors, associated electronics, and software 
processing. Guidance and autopilot functions are provided by software processing. 
Furthermore, all communications, both internal and external to the missile, are provided 
by MGS electronics and software processing. 

(2) Payload Section: The primary function of the payload 
section is to carry, protect, and dispense the payload of M74 grenades whose total weight 
is 350 pounds. The warhead has a safe and arm fuse, and a Skin Severance System (SSS), 
which controls the release of M74 grenades at the programmed time. The SSS includes 
an arrangement of Flexible Linear Shaped Charges (FLSC), which split the payload 
section skin into three panels. This action opens the payload compartment, allowing the 
entire load of grenades to disperse over target. 

Furthermore, the Payload Section has an embedded GPS antenna 
system, which is designed to operate in the high temperature environment involved with 
missile flight, and to perform in the presence of threat jammer signals. 
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(3) Propulsion Section: The propulsion system furnishes the 
energy necessary to launch the missile and sustain missile flight to meet ATACMS lA 
altitude and range requirements, and a Solid Rocket Motor (SRM) provides the thrust for 
the missile. The SRM consists of a motor case, propellant, insulation/liner, nozzle, and 
Igniter Arm/Fire Assembly. 

(4) Control Section Assembly: The primary functions of the 
Control Section Assembly (CSA) are to position missile fins, provide missile fli^t 
power, and perform selected pyrotechnic functions. The CSA consists of a Control 
Actuation Set, pyrotechnically activated electronics and control power batteries, four fin 
assemblies, an electrical harness, and a machined boat-tail structure. The CSA is attached 
to the aft end of the SRM surrounding the motor nozzle. 

(5) Enclosure Assembly and Launch Pod: The Enclosure 
Assembly and Laimch Pod (EALP) serves as a shipping, handling, transportation 
container, and launch pod for one missile to be fired fi-om a M270A1 launcher. The 
EALP is sealed for envirorunental protection, and is equipped -with desiccant to control 
humidity within the enclosure. 

b. MLRS M270A1 Launcher 

MLRS M270A1 Launcher is the platform firom which the ATACMS lA 
missiles are fired, and is capable of transporting and launching two ATACMS missiles 
consecutively. The M270A1 is comprised of a modified infantry fitting vehicle, and a 
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launcher/loader module. The tracked vehicle provides a multi-terrain capability and is the 
base for the M269 launcher/loader module, which houses two missile pods, each 
containing one missile. Electrical/electronic controlling devices are moimted in the M270 
for aiming and positioning the M269 in the azimuth and elevation axis. 

The M270A1 is designed for operation with a crew of three; a driver, 
gunner, and a chief crew. Additionally, it is equipped with an onboard Fire Control 
System (FCS) and Improved Position Determining System (IPDS). The FSC enables the 
crew to program fire missions while enroute to laimch points, reducing mission cycle 
time for the system. The IPDS determines azimuth reference data and launcher position 
data, and information from IPDS along with targeting information are transferred to the 
missile diuing pre-launch phase. 

The current M270A1 MLRS launchers, which are issued to units with 
deployment of ATACMS I missiles, will be utilized for ATACMS lA missiles witiiout 
significant modification for MLRS launchers except interface software modification. 
Additionally, launcher operating and support costs of the MLRS units will not be affected 
by the deployment of the ATACMS lA missiles, and there will not be additional 
operating personnel requirements for the system, except initial orientation training of the 
operating persormel. 
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c. Support Equipment 

The maintenance concept for ATACMS lA requires two levels of 
maintenance; namely ammunition general support level, and depot level maintenance. 
The required support equipments for those maintenance levels are Guided Missile Test 
Set at general support level and Missile Test Station Equipment (MTSE) at depot level 
support. In the succeeding paragraphs those support equipments will be discussed briefly. 

(1) Missile Test Device (MTD): MTD is a small portable test 
set that can perform electronic checks to determine the serviceability of an ATACMS lA 
missile in its EALP while not on board a launcher without affecting the integrity of that 
EALP. It will be utilized at ammunition supply points and at ATACMS lA maintenance 
facilities. 


(2) Missile Test Station Equipment Set: Missile test stations 
are used at Army ATACMS missile facilities to perform functional and diagnostic testing 
of ATACMS lA GMLAs. A missile test station has two kinds of equipment; Missile Test 
Station Equipment (MTSE) and Missile Test Station Augmentation Equipment 
(MTSAE). The MTSAE is used to perform detailed diagnostic testing of ATACMS lA 
Inertial Measurement Unit (IMU) and Control Section Assembly (CSA), and to print data 
stored in the GMTS. 
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d. Training Equipment 


The ATACMS lA training equipment consists of a Ml65 Guided Missile 
Traimng Set and a Guided Missile Test Set Trainer. In the following paragraphs, those 
training sets will be introduced briefly. 

(1) Ml65 Guided Missile System Training Set: The function of 
this training set is to support training of ATACMS Explosive Ordnance Disposal (EOD) 
personnel. The set provides familiarization training with the physical aspects of the 
missile and the location and identification of internal components. It also provides a 
capability for training EOD personnel to determine the GO or NO-GO status of the 
missile Arm/Fire and Safe/Arm Devices. 

(2) Guided Missile Test Device Trainer: The Fimction of The 
Guided Missile Test Trainer is to support training of Guided Missile Test Set Operators 
to perform GO-NO-GO status and surveillance testing of ATACMS lA missiles. The 
trainer is physically the same as the ATACMS EALP except it is equipped with ballast to 
stimulate missile weight, a malfimction panel, and other components to provide missile 
malfunctions to Missile Test Device. 

e. Computer Software Configuration Items 

The ATACMS LA missile system’s software subsystems consist of 
approximately 600,000 lines of code of which 200,000 lines are developmental, 370,000 
lines are modified and 40,000 lines are re-use software elements. Addition to Ada 
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language, which is the primary software implementation language for the mission critical 
computer software of the system, the other languages, namely Jovial, Assembly, Fortran, 
and Pascal, are utilized in development and integration of ATACMS lA software. In the 
subsequent paragraphs, the software subsystems of the system will be discussed. 

(1) Navigation and Guidance Computer Operational Flight 
Software (NOFS): This program is responsible for guiding and navigating the missile, 
and contains an executive program which performs alignment, navigation. Built In Test 
(BIT), auto pilot, guidance, and weapon dispense function. The guidance set software 
communicates with laimcher to perform its functions. 

(2) Navigation and Guidance Computer Inertial Program 
Loader Software (NIPLS): The general piupose of this program is to provide automatic 
control of the NOFS upon application of electronics systems power to the missile. 
Functions of the NIPLS include performing power-up BIT, loading fli^t software, 
transferring control to the flight software, purging classified data, and providing 
communications with Navigation and Guidance Computer, Inertial Sensor Computer, and 
the launcher. 


(3) Inertial Sensor Computer Software: this software sub 
system is responsible for communicating with the gyros and accelerometers. The 
functions of this software include BIT, alignment, accelerometer correction, gyro 
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correction, dynamic motion compensation, coordinate transformation, attitude reference, 
gimbal control, and autopilot filter fimctions. 

(4) Inertial Program Loader Software (IPLS): the functions of 
IPLS include performing power-up BIT, loading ISCP flight software, transferring control 
to flight software, and providing communications with Inertial Program Loading 
Software associated with Navigation and Guidance. 

(5) Embedded GPS Receiver Computer Program: This 
computer program enables the missile to interface with GPS satellite system, and 
provides continuous data flow to the NOFS and ISCS. 

(6) Control Actuation System Computer Program (CASCP); 
This program is responsible for arming Solid Rocket Motor (SRM), command destruct, 
enabling War Head, controlling fin actuators, BIT, umbilical break wire monitoring, and 
communicating with Improved Missile Guidance System. 

(7) Guided Missile Test Set Software: this software resides in 
GMTS and performs tests on the missile that determine the missile’s GO-NO-GO status. 

(8) Missile Test Set Software: This computer program resides 
in Missile Test station equipment and performs diagnostic tests for missile at depot-level 
maintenance. 
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(9) M270A1 Launcher Software: The Launcher software is 

embedded in launcher’s PCS and IPDS systems and enables those systems to perform 
their intended functions. 

3. System Operational Concept 

As stated previously, the ATACMS lA missile system will be deployed within the 
ammunition loads of corps MLRS battalions and divisional MLRS batteries, and will be 
fired against high value targets such as enemy Surface-to-Surface Missile Units; 
Command, Control and Communication sites etc. which are beyond the ranges of 
traditional artillery weapons. 

The deployment plan of the ATACMS lA missile system was formulated to 
minimize the cost of fielding by fielding of the system to existing MLRS units with no 
additional persoimel, and minimal additional training, rather than developing new units, 
and new Military Occupational Specialties (MOS). In this study, the nmnbers of fielded 
systems are considered cumulatively rather than on a unit-by-unit basis, because of 
security considerations. 

The ATACMS lA missiles have four modes and states; storage, pre-launch, 
flight, and dispense. The EALPs will be stored at ammunition supply points, and aside 
from training and military exercise piuposes, the missiles will be issued to MLRS units 
during contingency times. During storage mode, the EALPs will be stored in outside 
covered storage, and no major preventive maintenance will be required except aimual 
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inspections, surveillance testing, and corrosion control activities, if required. The pre¬ 
launch mode begins when the Guided Missile Launching Assembly (GMLA) is loaded 
onto the M270A1 Launcher and ends with missile launch. The activities involved with 
this mode include movement from the launcher re-load point to the missile firing point, 
upload of the missile flight software, conduct of pre-laimch procedures, and alignment 
transfer from the launcher to the ATACMS lA missile. The flight mode involves all the 
missile activities during time period from launching to tiie destination, target area. The 
payload of the missile is dispensed over the target area during the dispense mode. 

M270A1 MLRS Launchers will be stationed at the MLRS units, and were 
designed to be operated by the crew of three; a driver, a gunner, and a crew chief As 
stated previously, the fielding of the ATACMS lA missiles will not require additional 
O&S costs for the M270A1 MLRS Launchers, thus the O&S costs for the launchers are 
excluded in the LCC estimation for the ATACMS lA missiles. The deployment of 
missiles system will only require initial orientation training for the current launcher 
operators. 

4. System Support Concept 

The ATACMS lA system will utilize the standard Army support structure to the 
maximum extent possible and in accordance with the hitegrated Logistics Support Plan 
for the system. The support concept for the system differentiated between the hardware 
sub- system support and software sub-system support. The initial spares, repair parts, and 
required documentation for the system and sub-systems will be provided with the 
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deployment of the systems. The initial spares and repair parts requirements will be 
calculated through operational availability target values, considering the capacities and 
Turn Around Times (TAT) of the relevant support facilities. 

a. Hardware Support 

The ATACMS lA hardware maintenance will be performed at two levels; 
Ammuni tion Supply Support, which is equialvant to General Support (GS) and Depot 
Level Maintenance (D). The pecuhar maintenance and support activities for system 
hardware elements will be discussed briefly. The values of supportability performance 
parameters, such as MTBF, MTBM, Mean Maintenance Time, and maintenance material 
and personnel costs will be provided in the CASA model inputs. 

(1) Guided Missile Launch Assembly (GMLA): GS 
maintenance support will be performed by the Support Maintenance Company utilizing 
55 and 27 series of MOS persoimel. Support maintenance personnel (MOS 55) will 
replace desiccant, spot point, and perform limited repair of damaged external structural 
items, covers, and panels. Support persormel (MOS 27) will check a sample of missiles 
annually for GO or NO-GO status utilizing the MTD. GS maintenance of the GMLA will 
be limited to evaluation of missile components utilizing BIT capabihty with the MTD and 
examination of flie GMLA for evidence of moisture and serviceability. The rmserviceable 
GMLAs will be evacuated to depot and will be repaired at depot utilizing existing depot 
plant equipment, which has the capability to fault isolate to the Printed Wired Assembly 
(PWA) level. Repair of the missiles will be accomplished by replacement of major 
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assemblies, subassemblies, and/or components of subassemblies. In addition to those 
unscheduled repair activities, the fielded missiles will be exposed to scheduled periodic 
inspection, test and repair if required at depot level, as part of the missile surveillance 
plan. Spares/repair parts of the GMLA will be stocked at depot level. Unit level 
spares/repair part for GS maintenance activities described above will be stocked in 
Ammunition Support Companies. 

(2) Missile Test Device (MTD): GS maintenance of the MTD 
will be performed by the MOS 27 personnel assigned to the Ammunition Support 
Companies. The Operator utilizing the self-test capability of the MTD will fault-isolate to 
the sub assembly and/or components of subassembly. Repair of the MTD will be 
performed by replacement of the imserviceable item. The unserviceable items will be 
repaired at depot level. Additionally, the MTD will be calibrated within a scheduled time 
period. 


(3) Training Equipment; The GS level support of the training 
equipment will be performed by utilizing MOS 55 personnel assigned to the ammunition 
support companies, and most of the maintenance function of this equipment will be 
performed at that level. The depot level support will only be limited to major overhauls 
and modifications if required. 
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b. Software Support 


The Post Deployment Software Support (PDSS) of ATACMS lA system 
will be performed by the ARMY Software Support Center at depot level. The PDSS 
metrics will be provided in CASA model inputs section. 

B. COST ESTIMATION METHODOLOGY 

In order to develop the LCC cost estimate and to conduct cost risk (uncertainty) 
and cost sensitivity analyses of the ATACMS lA missile system, the Cost Analysis 
Strategy Assessment (CASA) Version 2000c Decision Support System (DSS) will be 
utilized. 

CASA was developed by the US Army Materiel Command Logistics Support 
Activity (USAMC LOGSA), and designed to provide support in the decision-making 
process for program managers assigned to materiel systems acquisition programs. 
Despite numerous LCC estimation software models being available in market place, only 
a few have capabilities to perform supportability, operational availabihty, and cost 
uncertainty-related analyses that help program managers address CAIV issues and 
optimize system design during system development stages. However, the CASA model 
is ideal for conducting such trade-off and sensitivity analyses as well as cost risk 
(uncertainty) analyses. The CASA model addresses the LCC of the objective system 
including RDT&E, EMD and Production, the learning and production rate curves, and the 
entire operational life during which the system is supported in the field. Virtually, every 
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cost associated with the system is covered by CASA, whether one-time, recurring, or 
annual. 


The CASA model utilizes a Monte Carlo simulation technique in order to 
simulate system, and/or subsystem failiures; elapsed maintenance times, turn around 
times, logistics delay times, and cost distribution functions, etc. However, the CASA 
model has only four kinds of statistical distribution functions in its library; constant, 
uniform, triangular, and normal distributions. The exponential, Poisson, and other useful 
statistical distribution functions are excluded; this can be regarded as one of the 
drawbacks of the model. However, if large numbers of systems, or subsystems are 
considered in the LCC estimation and analysis, and the estimation process involves a 
summation of different statistical distributions; the summation process results tend to 
approach a normal distribution due to the Central Limit Theorem discussed previously, 
and the drawbacks of the model are off-set. 

The CASA model has the inherent capability to consider and evaluate reliability 
growth or degradation of system or sub-systems, and their impact on system LCC, if 
applicable. This capability of the model enables the PMO to effectively model the 
“bathtub” behavior of system hardware components’ failure rates, and conduct reliability 
trade-off analyses for the specified system. 

For software development and PDSS activity costs, the CASA model utilizes a 
modified version of Constructive Cost Model (CoCoMo) as the software effort estimating 
methodology. The modified CoCoMo model utilizes lines of source code and other 
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adjustment factors such as program complexity, language level, and diversity as inputs 
and turns them into required man-months of efforts. 

Additionally, the CASA model has capabilities that enable the PM to calculate 
spares requirements for the desired service levels for each maintenance echelon, and 
evaluate the operational availability of the system. The operational availability module of 
the CASA utilizes two different approaches for operational availability assessments. The 
operational availability optimization method determines the maximum operational 
availability of the system within given constraints and adjusts the spares layout to achieve 
the maximum feasible operational availability. The other method, which is called target 
value method, enables the analyst to asses the spares requirements within the given 
support structure in order to realize the target operational availabihty value for the 
system. 

The CASA model performs the LCC estimation of the system under consideration 
through a summation process with approximately 82 algorithms. The model has 192 
variables, most of which are optional inputs that a cost analyst can tailor to the specific 
needs of the program. However, the CASA model does not have the capability to 
develop Cost Estimation Relationships (CER) utilizing comparable system cost data, 
rather it requires the analysts to develop CERs utilizing regression techniques first, 
estimate expected cost figures’ distributions for sub-systems, and plug those numbers into 
the model. If the CASA model had been designed to have a regression module, it would 
have been a very robust tool for the analysts. In this thesis; the cost elements such as 
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RDT&E costs, base unit production costs, learning and production rates have been either 
derived from ATACMS lA CARD, Selected Acquisition Reports (SAR), or assumed by 
the author utilizing ATACMS I cost data, since developing and validating those Wind of 
CERs is beyond the scope of the thesis. 

C. ESTIMATION ASSUMPTIONS AND CASA MODEL INPUTS 

1. Estimation Assumptions 

First, all the cost figures in the LCC development model are fictitious; they are 
generated by guidance from ATACMS lA CARD document and based on reasonable 
judgments by the author. Since, one of the objectives of the thesis is to explore the 
effects of system performance parameters such as MTBF,and MTTR on system LCC and 
operational availability, the objective will be realized regardless of the fictitiousness of 
cost figures. 

As stated in previous sections, all the costs, except launcher operator initial 
orientation trainmg costs, associated with M270A1 Laimcher are ignored since the 
deployment of the missile system will not incur additional costs associated with launcher. 
The only additional cost will be modification of launcher software modules, and the costs 
associated with launcher software modification efforts are included in initial software 
development costs. 

Although the total number of acquired systems and fielding schedule are derived 
from the actual acquisition schedule for the program, the numbers of General Support 


86 



units and Depots are fictitious. It is assumed that there are 10 General Support locations, 
each of which supports 80 missiles, and 2 Depot facilities, each of which supports 380 
units. The production and deployment schedules are provided in model inputs. 

Since the ATAMS lA is a missile, and req\iired to be mission ready at all times 
during deployment, it is assumed that the operations would be 24 hours per day, even if 
the missile were in a storage mode. In addition, it is assumed that the operator-required 
portion of this time is 0, since there are no operators associated with the missile itself 
The operators are associated with MLRS launchers. 

The slope of the learning curve and slope of the production rate associated with 
ATACMS lA production are assumed to be .90 and .95, respectively. In sensitivity 
analysis, the rate changes and their prospective effects on LCC will be evaluated 
separately. 


2. CASA Model Inputs 

The CASA Model inputs are provided in Appendix A. 

D. CASA RESULTS AND ANALYSIS 

1. LCC Cost Estimation Results 

In this subsection, the percentage distribution of the LCC major elements of 
missile system, which are RDT&E, Acquisition, and O&S costs are discussed. As 
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depicted in the Figure 17, the LCC major elements are distributed as 15%, 44%, and 41% 
for RDT&E, Acquisition, and O&S costs, respectively. 
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Figure 17: ATACMS lA LCC Distribution [Source Data: Appendix B] 

As discussed previously; the RDT&E costs cover all the efforts and cost 
commitments that are related to development of the s^em, whereas the acquisition costs 
cover all the cost elements that are incurred to manufecture, and to field the system with 
required support equipment, training equipmrait, documentation, and initial ^ares. Initial 
spare requirements are calculated through assumed confidence levels at maintenance 
echelons, which are 90% for General Support Level and 95% for depot level. 
Additionally, the acquisition costs include the initial software development and initial 
training costs. The interesting thing in distribution of Acquisition cost elements into 
lower level categories is that initial software development efforts constitute a significant 
portion of the system acquisition costs, which is approximately 36% of total acquisition 
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costs despite conservative assumptions being made for software development efforts. As 
stated in CASA inputs, the initial training requirements are classified as operator 
orientation, GS personnel training, and Depot pCTSOimel training. O&S costs cover all file 


efforts and cost commitments in order to sustain the system in the field, including the 
software maintenance, recurring training, and recurring documentation revision costs. 
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Figure 18: ATACMS LA Annual Cost Outlay in Constant 2001 Dollars 

[Sonrce Data: Appendix B] 


89 



























Figure 19: ATACMS lA Inflated Annual Cost Outlays [Source Data: Appendix B] 

The detailed figures for the CASA model LCC estimation for ATACMS lA are 
provided in Appendix B. 

2. Sensitivity Analysis 

In order to evaluate the marginal effects of system cost drivers and system 
supportability performance parameters on system LCC and operational availability, eight 
types of sensitivity analysis vidll be conducted. These evaluations will enable the 
decision-makers in system acquisition and support environments to make informed 
decisions on alternate system configurations, acquisition strategy and schedule, and 
stracturing the svstem support environment. 

First five of these analyses, which are MTBF, MTTR, Unit Cost, Tum-Over Rate, 
and Spares TAT sensitivity analyses, are conducted to evaluate tiieir marginal effects on 
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estimated LCC for the system. The following two analyses, which are Learning and 
Production Rate Curve sensitivity analyses, are performed to evaluate the changes in the 
system acquisition costs when the assumed learning and production rate slopes are 
changed. The author of the thesis preferred to perform sensitivity analyses for the learning 
and production rate slopes against the system acquisition costs rather than system LCC, 
since both of the cost-drivers are related to system production specifically. The last 
sensitivity analysis, which is operational availability sensitivity analyses, is conducted to 
evaluate the effects of MTBF, Spares Confidence Levels (CL), and System-Level 
Maintenance Elapsed Time (MET) on system operational availability. System-Level 
MET consists of S 3 ^etn active maintenance time, administrative delay time, and logistics 
delay time for system maintenance activities. System active maintenance time, that is a 
wei^ted mean value of MTTRs of the system for corrective and preventive maintenance 
actions, is primarily a system design decision; but the other ingredients of MET, which 
are administrative delay time and logistics delay times that includes transportation of flae 
system to applicable maintenance echelon, are related to the effectiveness and efficiency 
of the system support environment. However, during the system design period, the ^^em 
developers can perform an effective supportability analysis for the conceived system 
design that enables the systCTi to exploit the current logistics environment in most 
efficient and effective way. 

in the following sub subsections, the results of those sensitivity analyses are 
discussed. The data related to these sensitivity analyses are provided in Appendix C. 
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a. 


MTBF Sensitivity Analysis 


As discussed in the previous sections, the MTBF performance parameter 
denotes the time period in 'which system and its sub-systems or components functions in 
their intended ways -without a failure. The decrease in MTBF of the system or its 
components affo^ts systems LCC through an increased quantity of spare parts 
requirement at given confidence levels, increased amount of maintenance work required, 
and increased quantity of support equipment requirements and utilization. 

As seen in Figure 20, the relationship between MTBF and system LCC is 
negative in nature; the increase in MTBF decreases system LCC or -vice verse. However, 
if the system design and technology is the state-of-the-art-of available technology, then it 
generally requires investment in research and development acti-vities to increase the 
MTBFs of the system and its subsystems or conrponents. This requirement for pushing 
the edge of technology may increase system acquisition costs. 



Figure 20: ATACMS lA LCC Sensitivity to MTBF [Source Data: Appendix C] 
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As is clear from the Figure 20, the margmal benefits, in terms of system 
LCC reductions, of the improvements in MTBF decreases as the level of improvement 
increases. For example; increasing the MTBF from its 70% to the current level reduced 
the system LCC by $105,000,000 which means that the average LCC savings is 
$3,500,000 per one percent improvement in MTBF, whereas increasing the baseline 
MTBF to its 140% value promises LCC savings about $70,000,000 which translates 
$1,750,000 saving per one percent of improvement on average. This behavior of the 
curve obeys the general economics principle of decreasing marginal baiefits, and may 
provide guidance to the decision-makers in allocating resources for RDT&E acti^ties and 
system reliability improvement programs. 

b. MTTR Sensitivity An(dysis 

MTTR refers to maintainability of the system, sub-systems and then- 
components. MTTR affects sj^tem LCC costs through s>^em maintenance labor costs. 
As it is evident from the Finite 21; there is positive relationship between system or 
subsystem MTTR values and the system LCC, which states that as the MTTR values are 
increases, the system LCC cost increases proportionately. 
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Figure 21: ATACMS lA LCC Sensitivity to MTTR [Source Data: Appendix C] 

As depicted in the Figure 21, the sensitivity of LCC to MTTR values of 
the system and sub-systems or their components is calculated approximately as $100,000 
per one percent change in the baseline values. 

c. Spares Unit Cost Sensitivify Analysis 

Spares unit cost affects LCC through boft acquisition costs and O&S 
costs. The sensitivity analysis conducted to ^sess the effects of probable escalation rates 
for unit cost of spares and provide an enabling tool for the negotiations with contractors 
for either system acquisition, warranty discussions, or different types of system siq)port 
agreements. 


As pointed out in the Figure 22, there is a positive relationship between 
the spares unit costs and the system LCC; the marginal effect of 1% increase on spare unit 
costs is approximately $160,000 on the system LCC. The sensitivity chart reflects the 
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average changes on spares baseline cost jSgures rather than an item-by-item basis, hi 
order to evaluate the changes on the baseline unit cost figures for each spare item more 
specifically, a sensitivity analysis on item-by-item basis should be conducted. However, 
the author did not perform that kind of analysis, because of space limitations. 
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F^re 22: ATACMS lA LCC Sensitivity to Spares Unit Cost [Source Data: Appendix CJ 


d. Turn Over Rate (TOR) Sensitivity Anedysis 


TOR refers to the annual turn over rate of the employees associated with 
General Support and Depot level maintenance of the ATACMS lA missile. The launcher 
operator TOR is excluded jfrom this anal>sis; since all the costs associated with MLRS 
launcher are excluded fixim LCC estimation and relevant analyses, as stated in the 
assumptions section. 


The annual TOR of die maintenance and support employees ajffects system 
LCC throu^ recurring training requirements. As die TOR increases 1% of baseline 
value, the system LCC increases by approximately S10,000. This analysis may prove to 


95 
















be a valuable tool for tifate PMs and support facilities managers in developing strategies 
and allocating resources to employ those strategies in order to increase the retention rates 
of employees associated with the system. 



0 50 100 150 200 250 


Percent of Baseline | 

Figure 23: ATACMS L4 LCC Sensitivity to Maintenance Labor TOR 
ISource Data: Appendix C] 

& Spares TAT Sensitivity Anafysis 

The spares Turn Around Time (TAT) refers to the time period that is 
el^sed to replace a ^are unit, which is used to maintain the system, either by rq)aiTing 
the unserviceable one or purchasing a new spare unit As the spares TAT increases on 
average, the initial spares requirements increases to meet the confidence levels 
throughout the maintenance echelons or vice verse. This relationship is depicted in Figure 
24. 
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Figure 24: ATACMS LA LCX Sensitivity to Spares TAT (Source Data: Appendix C] 

As the chart points out, 1% change of baseline spares TAT increases the 
system LCC approximately by $50,000 on average. The spares TAT is the function of 
spares maintain ability, transportability, the efiSdency of the logistics support 
infrastructure, and the responsiveness of the organizations associated with that ^ares 
imit. Henceforth, tins analysis can be used as a decision enabler in evaluating 
maintainability and transportability alternatives for the system and its spares units during 
the system development period, and evaluating tire cost and benefits of improving the 
eflSciency of the system logistics mfi:astracture. 

/ Learning Curve Sensitivity Analysis 

Learning curves are associated with recurring production activities, 
therefore the sensitivity analysis is conducted to evaluate the effects of changes in 
assumed learning rates in system acquisition costs. As stated previously, the assumed 
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slope of learning curve for the system production is 90%. In the sensitivity analysis, 
system acquisition costs are calculated for the fractions of the baseline learning curve 
slope. The Figure 25 depicts the behavior of system acquisition costs for the changes of 
baseline learning rate. 



Figure 25: ATACMS lA Acquisition Cost Sensitivity to The Slope of Learning Curve 

[Source Data: Appendix C] 

The chart shows that the acquisition costs increase at an increasing rate, as 
the slope of learning curve increases that is the learning rate for the system recurring 
production activities decreases. The learning curve analysis provides leverage for cost 
analysis of the contractors’ production cost proposals, and enables the PMO to prepare 
budgeting requests and program cost estimates more effectively. Furthermore, leamins 
curve analysis proves to be an important tool in evaluating the alternative system 
production schedules through assessment of their effects on learning rates. 
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g. Production Rate Curve Sensitivity Anafysis 

Similar to leanung curves, the production rate curves are associated with 
system production activities; generally increased production rates decrease average cost 
of manufactured quantities through increased capacity utilization and reduction of 
production overhead costs and non-recuixing costs per manufactured unit. However, this 
rmderlying assumption holds within the boundaries of sustainable production capacity 
utilizations, beyond those points the average unit costs tend to increase because of 
required cost commitments for capacity increases and higher inventory holding costs. 

The slope of production rate curve refers to the degree of logarithmic 
relationship between production rate and system manufecturing costs; tihe relationship can 
be described such as the slope of the production rate curve gets hi^er value, the effects 
of production rate on system production costs get smaller. In order to test that 
assumption, and to assess the effects of different production rates on the production costs 
of the so-called system a sensitivity analysis is conducted for the Motions of baseline 
production rate slope, which is assumed to be 95%. 

Figure 26 provided below depicts the changes in the system acquisition 
cost estimates for different values of production rate slope. As is clear from tihe Figure 
26, the system acquisition cost estimate grows at an increasing rate as the slope of tihe 
production rate curve increases. The assessment of Me effects of different production rate 
slopes on system acquisition costs enables the acquiring agencies to evaluate the 
contractor’ cost proposals, develop production cost estimates for the system more 
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effectively, and structure the system acquisition and production schedule in a way that 
optimizes system production costs. 



Figure 26: ATACMS lA Acquisition Cost Sensitivity to The Production Rate Slope 

[Source Data: Appendix C] 


h. Operational AvaUabUity Sensitivity Analysis 

As discussed in previous ch^ters, the operational availability of the 
system refers to the probabili^ that the system under consideration would be available in 
operational status when needed during its operational life. The parameters of operational 
availability are system MIBF, and system level maintenance elapsed time (MET), which 
includes system MTTR, logistics down time that refers to the responsiveness of logistics 
system including transportation time, and administrative delay time that refers to 
responsiveness of the organization at which the S 3 ^em is operated. In order to assess the 
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marginal effects of those parameters on ^stem operational availability, sensitivity 
analyses are conducted for each of those parameters. Figures 27, 28, and 29 exhibit the 
results of those sensitivity analyses. 

Figure 27, which reflects operational availability sensitivity to the system 
level MTBF, dqjicts that the operational availability of the system increases at a 
decreasing rate as the MTBF increases. In other words, there is a decreasing marginal 
benefit, in terms of operational availability, of increasing the system level MTBFs either 
by pushing the edge of technology or introducing redundancy to the system at lower 
levels of the system hierarchy. This sensitivity analysis provides a firamework for 
conunitments for RDT&E ejSbrts for reliability improvements, and enables the system 
developers to assess the effects of alternative system designs on operational availability. 



Figure 27: ATACMS lA Operational Availabili^ Sensitivity to MTBF 

[Source Data: Appendix Cl 
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Figures 28 and 29 reflect the sensitivity of operational availability to 
spares Confidence Levels (CL) throughout maintenance echelons and system level 
maintenance elapsed time that is discussed above respectively. 



Figure 28: ATACMS lA Operational Availability Sensitivity to Spares CL 

(Source Bata: Appendix C] 

As clearly expressed in the chart, increasing spares confidence levels, 
which means increasing the quantity of ^are parts throughout maintenance echelons, 
beyond 90 % of baseline values, which are 90% and 95% for General Support and Depot 
levels respectively, does not yield a significant increase in operational availability for the 
system. Fur&ermore, this sensitivity analysis shows fliat there has been only a .0102 
improvement cumulatively in the operational availability of the system by increasing the 
confidence levels firom 50% of baseline values to the 100% of baseline values. These 
insights firom that sensitivity analysis provide valuable guidance to establish an 
^propriate confidence level for each of the maintenance echelons, and enables the PMO 
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to assess cost effectiveness of die increasing spar^ coxUSdence levels or increasing spares 
quantities associated with the system. 



Figure 29: ATACMS lA Operational Availability Sensitivity to System Level MET 

[Source Data: Appendix CJ 

Figure 29 points out the results of the sensitivity analysis conducted to test 
the operational availability sensitivity to system level maintenance elapsed time, which 
was discussed previously. As depicted clearly in the chart, decreasing system level MET 
promises significant improvements in operational availability of the system. For instance, 
decreasing baseline value of sj^em level MET by half (that is 50%) improves operational 
availability to .961 from .90. As discussed previously, the ingredients of system level 
MET are system level MTTR, logistics delay time, and administrative delay time; and 
only one of those ingredients, which is MTTR, is constrained by system design, the others 
are predominantly determined by the effectiveness of the lo^stics support infiastructure 
of the environment in which the system operates. Therefore, improving effectiveness of 
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the logistics system and eliminating non-value adding activities in tiie system si 5 )port 
process, promise permanent significant improvements in the operational availability of 
the system. 

Furthermore, when we compare the results of the MET sensitivity analysis 
with the results of the confidence level sensitivity analysis; it seems evident that 
improving the efficiency and effectiveness of logistics support organizations and 
processes is a more successful strategy to improve operational availability of the system 
than merely increasing spares confidence levels, in other words, increasing spare 
quantities throughout the maintenance echelons. 

3. Uncertainty Analysis 

hi order to assess the risk associated with the assumed cost structure for the 
system, an uncertainty anal}isis is conducted utilizing a Monte Carlo simulation technique 
which is embedded in the CASA cost estimating and analysis model. The CASA model’s 
risk analysis model has been limited to a maximum 200 simulation runs, therefore the 
ATACMS lA LCC cost risk analysis is limited to 200 simulation runs. Although 200 
simulation runs is a small number to determine appropriate distribution and probabilities 
of the potential LCC for the system, it gives an insight into the cost risk behavior of the 
s>-stem. hr Figures 30 and 31, the frequencies and cumulative probabilities of the 
potential values for system LCC are provided, respectively. The risk analysis results data 
is provided in Appendix D. 
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As discussed in Ch^ter H, the LCC estimation process inherently includes many 
imcertainties; therefore die probability of realization of a point estimate is almost zsro, 
regardless of the estimating methodology utilized. Henceforth, it is a prudent approach to 
express die cost estimates with dieir respective probabilities or with their probability 
distribution type and parameters such as mean value, standard deviation, etc. 



Figure 30: ATACMS lA LCC Frequency (200 Runs) 


[Source Data: Appendix D] 
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Fignre 31: ATACMS lA LCC Cnmnlative Probability Distribution 
[Source Data: Appendix D] 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

The acquisition of major systems requires long term cost commitments by the 
acquiring organizations, thus the resource allocation decisions must be based on life-cycle 
oriented analyses of so-called systems rather than analysis of the costs associated with up¬ 
front costs. 

As is discussed in ATACMS lA case, system sustainment costs constitute a 
significant portion of system LCC costs, thus system development efforts and source 
selection decisions in an acquisition environment must be based on Total Ownership Cost 
evaluations of the alternative system solutions. Additionally, the implementation of 
alternative business practices such as IPPD, and Concurrent Engineering help the system 
developers and acquisition practitioners reduce the TOC of the sj^tem and increase the 
operational availability of the system. Furthermore, the PMs should develop cost 
reduction and operational availability improvement strategies, not only considering the 
system itself, but also considering the system and its support environment as a whole, 
otherwise these cost reduction and operational availability improvement efforts will not 
be as efficient and effective as expected. 

The acquisition process, system development efforts, and cost estimation process 
which help decision makers allocate valuable resources to a program, or among programs 
have inherent uncertainties about future or expected program outcomes. Henceforth, the 
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cost uncertainty analyses about the expected program costs help the PMs uncover the 
costs risks associated with the program, develop realistic program cost estimates, and take 
appropriate measures such as PM’s management reserve proactively, thus the program 
will continue without significant breaks resulting from the unavailability of funds. 

B. RECOMMENDATIONS 

The cost estimation and analysis of the estimate results for ATACMS lA system 
have been performed by utilizing the CASA cost estimation tool developed by the US 
Army Materiel Command. 

Although the CASA model is very useful tool for developing LCC estimates, 
conducting sensitivity and uncertainty analyses by evaluating different system cost and 
supportability performance parameters and their impacts on system LCC and operational 
availability; the CASA should be improved in a way that enhances those capabilities, 
integrates the cost estimation techniques to the CASA such as incorporation of a data 
analysis and regression module, and includes all the statistical distribution functions, 
which are relevant to system performance and cost behaviors. 
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APPENDIX A. CASA MODEL INPUTS 
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APPENDIX B. ATACMS lA LCC ESTIMATION RESULTS 


1 

ATACMS lALCC Estimation 


i TOTAL LIFE CYCLE COST 




i 

1 




iTotal lUDT&E Cost 

$95,657,000 



ITotal Acquisition Cost 

$293,927,288 



iTotal Operation and Support Cost 

$269,103,010 



j 




ITOTAL LIFE CYCI^ COST 

$658,687,298 
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IEDT&E Cost 
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iResearch & Development 
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$27,740,530 


Demonstration and VaHdation 
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1 Software Center 
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i Operation and Support Costs 




\ 




1 

General Support 
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IRepair Labor 
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1 Support Eq^ Maint 
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APPENDIX C. SENSITIVITY ANALYSIS RESULTS 




i 1 

i i 

i 




i i 


iBcMlteonNT COST OXn SomitMtr Rns * 

t 



i 


T' f < lir iiiiin 




i 

J_ 

i 1 


i ! i 

i i 

HHHI 





I_i 


I.L.. .U,■!.!:■ 


ESSOHHI 

lOvcralhnd 


Lsr'-M 









^S3wm 

U 1 1 

[^m 

AniiAmt 

r 

BtadhwV 

ICortffl 

LdjJMiKLI 

\S3SM 











MHMj 


li^HHi 

mm^m 






40 


riw.v.^w 

BiiEGiLKT 

wirm^ 




iFr.W>Erji!il 

16^45389 




i i 

70 

wniws^ 

EmDE! 


IX'lITJfT 



tliJUiiE: 

267312,855 


HHHH 

pHHpi 

HHHH 


100 





BBS 



269,103,009 


hhhh 

HhHH 

^B 

HHHH 

140 

ESEiiyi; 


IfTrlWfWM 


SB^B 



271340,702 

1 II 111 ^— ■ 

p— 

BSBt 

bb 

HHHHi 

200 




0.956102 


HHEZ 

E£SHKi 



ijji—jj—j 


HHHH 

hhhh 


■■■■■hhhhi 

■MMi 





HHHH 

HHHHi 


i 

! 

.[._.. 

\ i 




i 

i&vateofMBANTIMB TO rMTOil Smit^ Haim 

;* I 

RcsiltaofMAZNIBNANCB PBBSONBLTIBNOTER EATS (TOR) SMshhritrRiiis* 




SBNsmvm:=si07i5(s / percent ofbasbunb) 




i 

1 

MMIH 


; 



I 1 









Total 



R!rSI!Ij 

tffr.vi’i’a 

OtantSoxaM 

Total 



1 





LCC(5) 


piiiiii^^ 


Z^IOHi 

LiiJMA'iLI 

IjCC($) 




I 

niiiiHi 

mam^ 



jlM^iiiiiiB 


HHHH 



I^HH 




i 

40 



IHHI 

taMumiHii 


feliALiMi 

EEXEE5g 

658.044.410 




1 

70 

389,584080 

n yji fci i l!> jti 

BHH 

piiliiipp^ 




r.y : jfcv^-^ . 




i 

100 

ELiltLIAIiJ 

W.vH! 1VIi! I> J :.V. .4jAI" i 


ppipiiiiiiiii|iM 


ssezRni 

EXESWia 


HHHH 

HHHH 

HHHH 

H^HHi 

140 

ia3SK3 

PITTTTTIPTirTrTTTirTiTl 


iilBlMM 

II^EE 

ElUtilRLiL 


[ 11 f ^ ^ II 1 


> 

! 

200 

E3E25II1 

F?!vTr77npTJlFI?ir>7il5r3 

m^m 















_ i .__ 


I 




1 


ResiltaofPRODDCTTONRAIE SLOPESonitMlT Rns* 


HHHH 

^HHHI 



ISBUNBli 

SENSillVITT = $525451500 ($ / PERCENT OF BASEUNB) 




p.... ...... . . P . - .. . . 



1 

! 






iPovodof 

Accndfitiom 

OvcntiDxn 

Total 


1 

ra^sEj 





HH^H 

^^HH 

hhhh 

hhhh 

k.rr:r^ 

SSCHI 

SmortCos^ 

LCCm 



rr:^rK 

s^^tghi 


issnm 

^■HH 

■ilHHI 

HHHH 

hhhh 

HHHH 



■■■■ 



1 

■■HI 


■HHHii 

■i^H 

^HH 

HHH 

—Hl| 

HHHH 

HHHH 

os 





i 

QO 

rsjcaii: 



HHIII^H 

^^HHI 

hhhh 

HHHHi 

OJS 






tZUCaiU 


HHHH 

HHIll^H 

hhhh 

hhhh 

0^ 



! 

oo 

iifICSHi 



HHHH 

HpHPH 

^^BHH 


0J9S 

335.704.011 269.103.009 604,807.021 



005 

23ESSSJ 



hhhh 

HHHH 

hhhh 

hhhh 




1 


ssEaiu 


HHHH 

HHHH 

■BB 

HHHHH 



H^HH 

HHHH 

HHHH 

HHHH 

HHHH 

IBcnteofSPABBS TOU^ODND TIMB (TAT) SouftMtr B»* 

RoOTltaofSPABBS CONFIDENCB LBVBL(CL) Saofthftr R»* 



i 

iSBNSmvnY =S60772 f$ / PERCENT OF BASBEJNB) 

i 

SENSmvnr = $7082222 ($/PERCENT OF BASELINE) 


HHHH 

bb 

HHHH 

; ; i 



i 

i 

1 ! 


HHHH 


^B 

IPaWflHtaf 


k! r wr* 





!L-i>i'r!?i 


Q3?H! 


HHHH 

hhhh 

hhhh 





HI^H 



^5u1H 


^4jHI 


HHHH 

HHH| 

■BB 

^— 



HHBH 


HBB 

BhhSB 

■^■■i 

HHHHi 

IHHHI 

I^HHlHHiHII 

HHHHI 

HHHH 

HHHH 

HHHH 

40 








^7■<^ET■^y■r■Tl 

EK2KI 


HHHHH 

HHHH 


H^H^H 

70 




HHHI 

HHHHHi 

■KES 


sansciai 



HHI^H 

HHHH 

HHHH 

HHHH 



aia[!ai^ai 

r^TyVAI-!! 


BSSi 

■■ES 

EBGad] 




HHHH 

hhhh 

HHHH 

hhhh 

140 

uirjicn 

ssnscia 




005 





i 



200 

EiEnca 

triiuiyiiiij 

rT.xj»iciW/-M 

HHH 


HHHEI 




0015895 

1 




Msm 


■■■■ 



HHHHHHHH 

HHHH 

HHHHH 




■■■■ 

■hhhhhhhI 

■hhmhhhh 

HHHHHHHHI 

HHHH 

HHHH 





HHHHHHHH 

■HHHHHH 

HHHH 

hhhh 


HII^H 

IIIIIIBHMB 


HHHjjjjM 

■HH 

HHHH] 

HHHH 

HHHHi 






■■■■■■■■I 

HHWH 

■■■■HH^H 

mSm 

hhhh 

HHHH 

HHHHH 


■■HHIHI 


■mHiH 

IHHII' 

’ 

1 

_ 


_ 




so 


0061 



i 

\ 







75 


WSHESk 




j 


I 



HHHH 


100 


■KEIES 


^■■ii 

■IHIIIIIIHIIIH 

HHHHHHHHI 

HIHlHi 

HHHHHHHH 

HHHHi 

bb 

HHHH 

HHHHH 

125 


■Kdi 




i 



HHHjjH 

WHHI 


^HH|H 

150 


0J789 




1 


■■■■■ 

HHHHI 



HHHHH 

175 


0J61S 



i 

1 


ggHHHH 

hhhh 

gHgl 


■hhii 

200 


■■Erini 



: 

1 


llljlflllllllB^^ 

^BH 



HHHHi 




. i . 

1 


_^_ 


_ 

_j 


117 































































































































































TfflS PAGE IS INTENTIONALLY LEFT BLANK 


118 




APPENDIX D. COST RISK ANALYSIS RESULTS 


iLCC MONTE CARLO REST3LTS 


- 1 






iMiiiutiiiitt 

Maxiinum 

Mean 

Standard Deviation 


633,742,677.40 

$ 674,291,920.00 


654,988,589.02 

$ 9.192,608.21 








LCC Frequency Table 
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